UWS times

[Matthew Graham]

Hi,

The IVOA should be consistent in its standards in how this is dealt with. The date used in VOEvent for the creation of the packet is assumed to be UTC (with a trailing Z in the example given in the spec) and a subset of STC is used for describing the actual event so the timeframe is explicit here. What other standards mention time?

	Cheers,

	Matthew

On Mar 24, 2016, at 7:26 AM, Harry Enke wrote:

> Dears,
> just as additional thought:
> 1. not all implementations are done in java,
> 2. thus the easiest implementation for the purpose should be chosen, which still satisfies the minimal compliance with standards,
> not relying on any special language features,
> 
> 3. And, as a note for further perusing of other IVOA recommendation revisions:
> one of the problems is that instead of general standards (where applicable), special implementations are often chosen as model for the IVOA, glaringly so with ADQL built on MS-SQL.
> 
> Best,
> Harry
> 
> 
> 
> Grégory Mantelet wrote:
>> 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.
>>> 
>> 
> 
> -- 
> ******************************************************************
> * Dr. Harry Enke                      E-Science & Supercomputing *
> *                                       Phone : +49-331-7499-433 *
> * Email : henke at aip.de                  FAX   : +49-331-7499-526 *
> ******************************************************************
> * Leibniz Institut für Astrophysik Potsdam  (AIP)                *
> * An der Sternwarte 16,                     D-14482 Potsdam      *
> * Vorstand: Prof. Dr. Matthias Steinmetz, Matthias Winker        *
> * Stiftung bürgerlichen Rechts                                   *
> * Stiftungsverzeichnis Brandenburg:         26 742-00/7026       *
> ******************************************************************
>