<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 13, 2015 at 3:21 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><p dir="ltr">> If you are going to make datetime64 more like datetime.datetime, please consider adding the "fold" bit.  See PEP 495. [1]<span style="color:rgb(34,34,34)"> </span></p></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><p dir="ltr"><span style="color:rgb(34,34,34)">The challenge here is that we literally do not have a bit too use :-) </span></p></div></div></blockquote><div><br></div><div>hmm -- I was first thinking that this could all be in the timezone stuff (when we get there), but while I imagine we'll want an entire array to be in a single timezone, each individual value would need its own "fold" flag.</div><div><br></div><div>But in any case, we don't need it 'till we do timezones, and my understanding is that we aren't' going to do timezones until we have the mythical new-and-improved-dtype-system.</div><div><br></div><div>So a future datetime dtype could be 64 bits + a byte of extra info, or be 63 bits plus the fold flag, or...</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><p dir="ltr"><span style="color:rgb(34,34,34)">Unless we make it datetime65 + 63 bits of padding, stealing a bit to use for fold would halve the range of representable times, and I'm guessing this would not be acceptable?</span></p></div></div></blockquote><div>well, not now, with eh fixed epoch, but if the epoch could be adjusted, maybe a small range would be fine -- who need nanosecond accuracy, AND centuries of range?</div><div><br></div><div>Thinking a bit more here:</div><div><br></div><div><br></div><div>For those that didn't follow the massive discussion on this on Python-dev and the new datetime list:</div><div><br></div><div>the fold flag is required to round-trip properly for timezones with discontiguous time -- i.e. Daylight savings. So if you have:</div><div><br></div><div>2015-11-01T01:30</div><div><br></div><div>Do you mean the first 1:30 am or the seconds one, after the DST transition? (i.e. in the fold, or not?)</div><div><br></div><div>So it is key, for Python's Datetime, to make sure to keep that information around.</div><div><br></div><div>However: Python's datetime was designed to be optimized for:</div><div>  - converting between datetime and other representations in Database, etc.</div><div>  - fast math for "naive time" -- i.e. basic manipulations within the same timezone, like "one day later"</div><div>  - Fast math for "absolute relative deltas" is of secondary concern.</div><div><br></div><div>The result of this is that datetime stores: year, month, day, hour minute second, microsecond</div><div><br></div><div>It does NOT store some time_unit_since_an_epch, like unix time or numpy datetime64.</div><div><br></div><div>Also, IIUC, when you associate a datetime with a timezone, it stores the year, month, day, hour, second,... in the specified timezone -- NOT in UTC, or anything else. This makes manipulations within that timezone easy -- the next day simply  required adding a day to teh day field (then normalizing to the month).</div><div><br></div><div>Given all that -- the "fold" bit is needed, as a particular datetime in a particular timezone may have more than one meaning.</div><div><br></div><div>Note that to compute a proper time span between two "aware" datetimes, it is necessary to convert to UTC, do the math, then convert back to the timezone you want.</div><div><br></div><div>However, numpy datetime is optimized for compact storage and fast computation of absolute deltas (actual hours, minutes, seconds... not calendar units like "the next day" ). </div><div><br></div><div>Because of this, and because it's what we already have, datetime64 stores times as "some number of time units since an epoch -- a simple integer.</div><div><br></div><div>And because we probably want fast absolute delta computation, when we add timezones, we'll probably want to store the datetime in UTC, and apply the timezone on I/O.</div><br>Alexander: Am I right that we don't need the "fold" bit in this case? You'd still need it when specifying a time in a timezone with folds.. -- but again, only on I/O</div><div class="gmail_quote"><br></div><div class="gmail_quote">-Chris</div><div class="gmail_quote"><br></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>