<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 &#39;DATE&#39; == ISOTime type</div><div>       * the real param &#39;MJDREF&#39; == MJD date</div><div>       * the real field &quot;time&quot; == TIMEOFFSET</div><div>     We CAN have 1 type for JD, MJD, ISO ... what would be the datatype of the value? presumably &#39;datetime&#39;</div><div>     which would need to take on the broader &quot;string&quot; or &quot;real&quot; handling described earlier (if string =&gt;ISOTime, if &lt; 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 &#39;Demleitner&#39;s conjecture&#39;, 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 &lt;<a href="mailto:sla@ucolick.org">sla@ucolick.org</a>&gt; 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>
&gt; The time of LIGO-Virgo events is reported in ISO8601, like this:<br>
&gt;<br>
&gt; &quot;DATE-OBS&quot;: &quot;2017-08-17T12:41:04.429237&quot;<br>
&gt;<br>
&gt; 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                    &lt;<a href="mailto:sla@ucolick.org" target="_blank">sla@ucolick.org</a>&gt;              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>