<div dir="ltr"><div dir="ltr">Well... its nice to see people are reading the mails!<div><br></div><div>Markus:</div><div><br></div><div>It comes down to this..</div><div> o the model is not saying anything about serializations, but rather what sorts of data we need to represent.</div><div> o one use case being served by these elements is the event list, where we have</div><div> + creation time as FITS string (ISOTime)</div><div> + reference time for events MJDREF in (MJD) </div><div> + event times in sec from reference time (TIMEOFFSET)</div><div> In presenting this data, I want to explicitly identify what each of these types are</div><div> * the string param 'DATE' == ISOTime type</div><div> * the real param 'MJDREF' == MJD date</div><div> * the real field "time" == TIMEOFFSET</div><div> We CAN have 1 type for JD, MJD, ISO ... what would be the datatype of the value? presumably 'datetime'</div><div> which would need to take on the broader "string" or "real" handling described earlier (if string =>ISOTime, if < 2400000.5... )</div><div> But, in my opinion, it is better to be explicit here.</div><div> As trivial as it might be, it is not reasonable to force the data providers to convert their reference times to JD.</div><div> o we had a long thread some time ago about the offset in TimeFrame.. it boiled down to something like,</div><div> The TIMEOFFSET and MJD are in the same frame.. so refer to the same TimeFrame instance. The</div><div> offset itself should not be in the TimeFrame, because it does not apply to the MJD.</div><div> 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%..</div><div> I genuinely hope the odds are better than that.</div><div><br></div><div>Mark</div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jan 12, 2019 at 2:33 PM Steve Allen <<a href="mailto:sla@ucolick.org">sla@ucolick.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Sat 2019-01-12T13:48:58+0000 Roy Williams hath writ:<br>
> The time of LIGO-Virgo events is reported in ISO8601, like this:<br>
><br>
> "DATE-OBS": "2017-08-17T12:41:04.429237"<br>
><br>
> Python is pretty happy about ISO8601 (see below).<br>
<br>
If your machine knows that local timezone is equivalent to UTC, which<br>
I believe it is during the winter, then the Python routines will take<br>
this string without zone indicator as UTC.<br>
<br>
Naively(*) my mileage would vary at any time of year, and yours<br>
should vary during the summer.<br>
<br>
(*) In my code I take pains to ensure that when I am using<br>
off-the-shelf date parsing code I have that thread operate<br>
in an environment which I have explicitly reset to UTC.<br>
<br>
--<br>
Steve Allen <<a href="mailto:sla@ucolick.org" target="_blank">sla@ucolick.org</a>> WGS-84 (GPS)<br>
UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855<br>
1156 High Street Voice: +1 831 459 3046 Lng -122.06015<br>
Santa Cruz, CA 95064 <a href="https://www.ucolick.org/~sla/" rel="noreferrer" target="_blank">https://www.ucolick.org/~sla/</a> Hgt +250 m<br>
</blockquote></div>