UWS times

[Paul Harrison]

> On 2016-03 -23, at 16:57, Walter Landry <wlandry at caltech.edu> wrote:
> 
> Paul Harrison <paul.harrison at manchester.ac.uk> wrote:
>> 
>>> On 2016-03 -23, at 08:52, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
>>> 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.
> 
> It is a huge implementation issue if you want to do it correctly.  It
> is just that most people do not do it correctly, because that would
> require a historian.  I really do not want to worry about Samoa moving
> itself back and forth over the international dateline, or whether I am
> on Eastern or Western Kiribati.  Even accounting for leap seconds
> introduces problems that most people ignore.  For example, it is not
> correct to subtract MJD's.
> 
> Cheers,
> Walter Landry


It is a fallacy to say that you need to be an historian, geographer or lawyer when programming at the application level - you simply have to trust the delta hour designation when reading a timestamp (to calculate UTC) or trust that the OS has been set into the correct timezone when producing a timestamp - it is really not that difficult.

See http://www.cl.cam.ac.uk/~mgk25/iso-time.html#zone for a good write up on this.

I accept that it is simpler overall to avoid the arithmetic and just to pick UTC as the timezone to work in - where I differ from the DALI recommendation at the moment is that I think that the ‘Z' UTC timezone specifier should be added to the datetime string to make it portable to other contexts where the UTC is not mandated, as otherwise the correct thing for software to do is to interpret it as a local time. 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.

Cheers,
	Paul.