UWS times

[Paul Harrison]

> On 2016-03 -23, at 08:52, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> Dear GWS,
> 
> Yesterday, Paul made a commit to the UWS document with the following
> log message[1]:
> 
>> make the example time actually have UTC timezone, but do not mandate
>> in the language - any timezone should be supported
> 
> -- and that,... well, shock is probably to hard a word, but you get
> the idea.  I frankly have never noticed the intention of allowing
> time zones in UWS time stamps, although admittedly the example Paul
> fixed in this commit was clear enough.
> 

Well the change was made to be consistent with UWS 1.0 which did allow full ISO 8601
date times, and the assumption for most of UWS 1.1 was that it was still using ISO 8601 -
indeed the example instance of a <uws:job> still has a timezone adjustment in the timestamps.


> So, excuse me for bringing this up so late, but I think this is
> serious enough to even make me propose an erratum if we can't fix the
> text any more.
> 
> This being machine readable data, I'd argue strongly we should
> require, in effect, UTC (more exactly, timestamps without timezone,
> since I'm not really concerned if someone uses TAI or TDB if they
> like; there just shouldn't be time zones).
> 
> The main reason is: Supporting time zones is a *huge* implementation
> concern (unless you put serious restrictions over ISO 8601), and
> given things like daylight savings time, makes the standard
> susceptible to lawmaking in the greater world.  Also, while explicit
> time zone notation (e.g., CEST vs. CET) mitigates that particular
> problem, local times have hours that pass twice (next autumn for us)
> and ones that don't pass at all (this Sunday morning in much of
> Europe).

I am not convinced that it is such a huge implementation issue - the libraries for support must surely be in
place in most environments as ISO 8601 timestamps are pretty widespread. If you restrict yourself to the +/- hh:mm timezone
designation then there are no problems with ambiguity - however I do agree that it all can cause
confusion if not used properly though.

> 
> Such considerations made us restrict timestamps in the VO to what
> DALI 1.0 says in 3.1.2 (cf.
> http://ivoa.net/documents/DALI/20131129/REC-DALI-1.0-20131129.html),
> which is (after a correction that comes in in 1.1),
> YYYY-MM-DD[Thh:mm:ss[.sss]].  So, the second reason I'd strongly
> argue UWS should make clear what kind of times in which form should
> be used is consistency with the rest of the VO.
> 
> I think the simplest way to make that happen would be by replacing
> all references to [std:iso8601] to DALI and specify, where
> appropriate, that the full form with T and time is to be used.

I have to admit that I was not aware of this and given that this has already been standardised in DALI then it does seem that it is pretty much essential that UWS 1.1 be brought into line and use UTC without a timezone designator.

> 
> True, that is a change that might theoretically invalidate existing
> services, but really: Does anyone put in anything else but UTC into
> the time fields?


I am happy with UTC - I live in the UK and work at an observatory  - it is very natural for me as our computer clocks always tell UTC, but it might not be for others.

What have people actually been doing in their implementations? I suspect that as most of the implementations have been connected to TAP services (which are probably DALI compliant) so that people have probably been using timestamps without timezone designators, and hopefully UTC. I imagine that it would not be a big disruption to change any existing non DALI timestamp compliant services. In java for instance it would be just a case of explicitly setting the timezone to UTC and then having a custom date formatter that did not emit the timezone specifier.

As for how much of a change to the formal standard this would be, it seems that as we have not reached the REC stage then this update to be DALI compliant can still be made.

Paul.