[DRMAA-WG] DRMAA2: Partial time stamp discussion

[Daniel Templeton]

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 at ogf.org
>   http://www.ogf.org/mailman/listinfo/drmaa-wg
>