[DALI] timestamp format

[Rob Seaman]

Pertaining to expressions of time, those attending the January AAS in Washington, DC should consider participating in the session beginning 20140105T180000Z:

	http://www.cacr.caltech.edu/futureofutc/aas223/

Caveats and exceptions are inherent.

Rob
—

On Nov 6, 2013, at 9:57 AM, Dave Morris <dave.morris at metagrid.co.uk> wrote:

> 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.