DRMAA2: Partial time stamp discussion
Dear all, this discussion thread is intended to clarify the future of partial time stamps in DRMAA2. This feature of DRMAA 1.0 allows the expression of relative time information (e.g. "Start the job on next Monday"). It is used for the job template attributes "startTime" and "deadlineTime". The DRMAA2 survey clearly showed that this is an unnecessary feature from the user perspective. From our actual knowledge, no implementation beside SGE supports it. The standard implementation strategy instead is to support complete date / time information in the DRMAA string format, which is not compatible to anything. The Condor experience report discusses this to a great extend, and proposes ISO8601 resp. RFC822 as new data format for time information. The following questions need to be clarified: Is there any unknown use case / existing application for the partial time stamp feature ? Does it prevent us from dropping it ? What time standard could act as replacement ? Is this time standard mappable to all relevant programming languages (and their native date / time representation) ? Is this time standard mappable to all relevant DRM systems ? Can the standard also support the expression of an amount of time (TimeAmount IDL type, used for limit values in job templates) ? Please post the perspective from your favorite DRM system / programming language. Thanks, Peter.
Answers inline ...
this discussion thread is intended to clarify the future of partial time stamps in DRMAA2. This feature of DRMAA 1.0 allows the expression of relative time information (e.g. "Start the job on next Monday"). It is used for the job template attributes "startTime" and "deadlineTime".
The DRMAA2 survey clearly showed that this is an unnecessary feature from the user perspective. From our actual knowledge, no implementation beside SGE supports it. The standard implementation strategy instead is to support complete date / time information in the DRMAA string format, which is not compatible to anything.
The Condor experience report discusses this to a great extend, and proposes ISO8601 resp. RFC822 as new data format for time information. The following questions need to be clarified:
Is there any unknown use case / existing application for the partial time stamp feature ? Does it prevent us from dropping it ?
I never saw anybody using this.
What time standard could act as replacement ?
I obviously vote for ISO8601 or RFC822. RFC1123 is an updated version of RFC 822 with Y2K support.
Is this time standard mappable to all relevant programming languages (and their native date / time representation) ?
Some analysis: .NET languages: Both standards supported (" DateTimeFormatInfo" class) for conversion to native format Java: JSR-310 promises ISO8601 support for Java 7 (?), "java.text.SimpleDateFormat" provides RFC 822 conversion C: printf() formatting strings to be used (?) Python: ISO8601 and RFC1123 support
Is this time standard mappable to all relevant DRM systems ?
Condor handles date / time information in the classical Unix way, as number of seconds since Unix epoch. Conversion is therefore always needed with the above choices. We might consider Unix epoch seconds as third approach. /Peter.
I agree that the PartialTimestamp needs to go. No one has ever used it, and it's by far the hardest part of the Java language binding implementation. Regular date objects are more than sufficient. As for which date/time standard we pick, I don't so much care. Like with Condor, whatever we pick will have to be converted for SGE. Because Java uses RFC822 timezone format, I tend towards RFC822, but I can be swayed. Daniel Peter Tröger wrote:
Answers inline ...
this discussion thread is intended to clarify the future of partial time stamps in DRMAA2. This feature of DRMAA 1.0 allows the expression of relative time information (e.g. "Start the job on next Monday"). It is used for the job template attributes "startTime" and "deadlineTime".
The DRMAA2 survey clearly showed that this is an unnecessary feature from the user perspective. From our actual knowledge, no implementation beside SGE supports it. The standard implementation strategy instead is to support complete date / time information in the DRMAA string format, which is not compatible to anything.
The Condor experience report discusses this to a great extend, and proposes ISO8601 resp. RFC822 as new data format for time information. The following questions need to be clarified:
Is there any unknown use case / existing application for the partial time stamp feature ? Does it prevent us from dropping it ?
I never saw anybody using this.
What time standard could act as replacement ?
I obviously vote for ISO8601 or RFC822. RFC1123 is an updated version of RFC 822 with Y2K support.
Is this time standard mappable to all relevant programming languages (and their native date / time representation) ?
Some analysis:
.NET languages: Both standards supported (" DateTimeFormatInfo" class) for conversion to native format Java: JSR-310 promises ISO8601 support for Java 7 (?), "java.text.SimpleDateFormat" provides RFC 822 conversion C: printf() formatting strings to be used (?) Python: ISO8601 and RFC1123 support
Is this time standard mappable to all relevant DRM systems ?
Condor handles date / time information in the classical Unix way, as number of seconds since Unix epoch. Conversion is therefore always needed with the above choices. We might consider Unix epoch seconds as third approach.
/Peter. -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
participants (2)
-
Daniel Templeton -
Peter Tröger