Well... its nice to see people are reading the mails!
Markus:
It comes down to this..
o the model is not saying anything about serializations, but rather what
sorts of data we need to represent.
o one use case being served by these elements is the event list, where we
have
+ creation time as FITS string (ISOTime)
+ reference time for events MJDREF in (MJD)
+ event times in sec from reference time (TIMEOFFSET)
In presenting this data, I want to explicitly identify what each of
these types are
* the string param 'DATE' == ISOTime type
* the real param 'MJDREF' == MJD date
* the real field "time" == TIMEOFFSET
We CAN have 1 type for JD, MJD, ISO ... what would be the datatype of
the value? presumably 'datetime'
which would need to take on the broader "string" or "real" handling
described earlier (if string =>ISOTime, if < 2400000.5... )
But, in my opinion, it is better to be explicit here.
As trivial as it might be, it is not reasonable to force the data
providers to convert their reference times to JD.
o we had a long thread some time ago about the offset in TimeFrame.. it
boiled down to something like,
The TIMEOFFSET and MJD are in the same frame.. so refer to the same
TimeFrame instance. The
offset itself should not be in the TimeFrame, because it does not
apply to the MJD.
o According to 'Demleitner's conjecture', there is only a 52% chance of
uptake of this model, the consolidation of these 3 types would bring that
up to 55%..
I genuinely hope the odds are better than that.
Mark
On Sat, Jan 12, 2019 at 2:33 PM Steve Allen <sla at ucolick.org> wrote:
> On Sat 2019-01-12T13:48:58+0000 Roy Williams hath writ:
> > The time of LIGO-Virgo events is reported in ISO8601, like this:
> >
> > "DATE-OBS": "2017-08-17T12:41:04.429237"
> >
> > Python is pretty happy about ISO8601 (see below).
>
> If your machine knows that local timezone is equivalent to UTC, which
> I believe it is during the winter, then the Python routines will take
> this string without zone indicator as UTC.
>
> Naively(*) my mileage would vary at any time of year, and yours
> should vary during the summer.
>
> (*) In my code I take pains to ensure that when I am using
> off-the-shelf date parsing code I have that thread operate
> in an environment which I have explicitly reset to UTC.
>
> --
> Steve Allen <sla at ucolick.org> WGS-84 (GPS)
> UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat
> +36.99855
> 1156 High Street Voice: +1 831 459 3046 Lng
> -122.06015
> Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20190114/9b71997c/attachment.html>