UWS times

[Patrick Dowler]

The initial (most upstream) reference to timestamps in the IVOA and
use of this format is not in DALI - it is in section 2.2 of VOResource
and the UTCTimestamp type. DALI simply adopted that same restriction
and tried to put it is simpler language. Maybe there is a clear
reference missing...

Also, UWS probably shouldn't refer to DALI for this because DALI
already refers to UWS. It is not a very substantive reference, but we
should avoid circular references.


On 24 March 2016 at 11:12, Pierre Fernique
<Pierre.Fernique at astro.unistra.fr> wrote:
>
> Hi,
>
> MOC uses FITS convention (DATE FITS keyword in the MOC FITS header)
> HiPS should use the same UTC convention, but with an explicit trailing Z
> (hips_release_date, and hips_creation_date properties)
>
> So the same convention that VOEvent it seems.
>
> Cheers
> Pierre
>
>
> Le 24/03/2016 15:54, Matthew Graham a écrit :
>>
>> 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       *
>>> ******************************************************************
>>>
>



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada