UWS times

[Grégory Mantelet]

Hello Grid,

     In my UWS library, I output destruction, start and end times in 
UTC, with a Z at the end. But I allow the library users to output the 
time zone shift if they want to.

     I am also recently able to support a lot of various 
ISO-8601-compliant times in input for the new HTTP-GET parameter AFTER ; 
thus a part of a timestamp (e.g. month, year, day, full date, 
date+hours, ...) should be perfectly well interpreted by my library. 
Since I did not want to rely on an external Java library or on a too 
recent version of Java, I develop myself this ISO8601 parser/formatter. 
It was indeed not so trivial, but not really a nightmare to do.

     So, my opinion on that subject is as follow:

         1. I agree that having all dates in UTC is a better idea, 
because it is simpler and make the understanding of dates/times clearly 
explicit.

         2. However, I also agree with Paul on the fact that the Z 
character should be appended to be really conform with the ISO-8601 
standard. An external client (TOPCAT may not be the only one) reading 
XML documents produced by a UWS (and maybe also DALI) service should be 
able to interpret correctly dates ; for that, dates should be formatted 
in a correct ISO-8601 format.

         3. We should not forget that we have now also to deal with 
ISO-8601 dates with the new UWS-1.1 parameter AFTER. Though, it is true 
that the Proposed Recommendation states that AFTER dates should respect 
ISO-8601 and should be in UTC. So, there may be no worry about this point.

Cheers,
Grégory


On 03/24/2016 01:38 PM, Paul Harrison wrote:
>> On 2016-03 -24, at 10:07, Mark Taylor <M.B.Taylor at bristol.ac.uk> wrote:
>>
>> On Thu, 24 Mar 2016, Paul Harrison wrote:
>>
>>> TOPCAT is a good example of a tool that is designed to work with data
>>> from both VO and non-VO sources and cannot make the assumption that
>>> every datetime it sees is UTC - to be able to do meaningful comparisons
>>> it needs the timezone information.
>> Umm, as far as I remember[*], I'm afraid it makes exactly that assumption.
>> In conversions it tolerates a trailing Z, but that's about it.
>> Although it (sloppily) mentions ISO-8601 in various parts of the
>> documentation, it will choke on many ISO-8601-compliant time strings,
>> including ones with trailing [+-]hh:mm modifiers.
>>
>> I never looked hard at how much effort it would be to treat all
>> ISO-8601 strings properly (quite likely you can just throw them at
>> some java class),
>  From Java 7 it is built-in http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html - JodaTime can be used before that.
>
>> but I followed the restricted profile allowed
>> by FITS on the grounds that it's less confusing and satisfies most
>> people's requirements.  I don't recall anybody ever complaining
>> about topcat/stilts's failure to work with more general ISO-8601
>> strings.  So, I'd line up on the "make'em eat UTC and like it"
>> side of the argument (though preferably without disrupting
>> existing standards text too much if possible).
> All I am arguing for is that the Z at the end should be mandatory so that it is explicit that UTC is being used.
>
> Cheers,
> 	Paul.
>