[DALI] timestamp format

[Dave Morris]

Option (1), explicitly stating the implied 'Z' would cause the least 
astonishment for our users.
[http://en.wikipedia.org/wiki/Principle_of_least_astonishment]

In reality an end user writing a simple client side program is not going 
to read through all of the detailed small print in our standard. They 
are going to run a test query, look at the data it returns and write the 
simplest bit of code to process it, missing the detailed nuances of the 
implied 'Z' that isn't there. If they then upload their results to 
another VO service, it will (should) assume the missing 'Z' and store 
(and re-publish) the data as UTC.

Run through a sequence of four or five download/process/upload steps, 
and the data will drift further and further away from the original 
values. If one or more of the download/process/upload steps crosses the 
Atlantic between CADC in Canada (UTC-7H/UTC-8H) and INAF in Italy 
(UTC+1H/UTC+2H) then depending on the direction of transfer and whether 
the software at each end is or is not aware of the impled 'Z', the 
resulting timestamps may end up being several days different from the 
original values.

The problem is that without the explicit 'Z', things will quietly 
produce the wrong results without signalling an error.

     IVOA custom software that is aware of of the impled 'Z' will treat 
the data as UTC.
     ISO standard software that is not aware of the special case for IVOA 
data will assume local timezone and add the appropriate offset.
     Software that is not aware of either the ISO or IVOA standards may, 
or may not, add the local timezone offset.

If we explicitly state the 'Z', then software that does not understand 
what it means will fail with an error.

     IVOA custom software that understands the 'Z' will treat the data as 
UTC.
     ISO standard software that understands the 'Z' will treat the data 
as UTC.
     Software that is not aware of either the ISO or IVOA standards will 
fail to parse the 'Z' - making it clear that something is wrong.

Being able to refer to the existing ISO8601 standard without caveats or 
exceptions will make it easier to promote the use of the IVOA standards 
in wider inter-disciplinary collaborations.

Last week saw the first meeting of a new project, AstroTrop 
[http://www.astrotrop.org/], which aims to re-use the IVOA standards and 
software developed by AstroGrid in a new collaboration
with the TROPGLOBE network of tropical forest scientists.

However, I must admit that beyond having to test and update our existing 
software, I don't know what the full side effects and costs of adding 
the extra 'Z' are.

Is anyone else aware of the technical issues raised by explicitly adding 
the 'Z' ?

Thanks,
Dave

On 2013-11-05 20:19, Patrick Dowler wrote:
> 
> So, common IVOA usage (and as I understand the "ISO8601 profile" in
> the FITS community) is not consistent with ISO8601.
>