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.