<div dir="ltr">Hi Matti and Stefano,<div><br></div><div>My understanding is that datetime64 was decided to be neither TAI nor posix time, but rather represent an abstract calendar point, like datetime.datetime without a specified timezone. This can usually be converted into posix time given a timezone (although in the "repeated" hour between DST and winter time there will be ambiguity!) If it is agreed by all users that a datetime64 represents the time in UTC, it is the same as posix time.</div><div><br></div><div>I would like to have a type that is defined to be equivalent to posix time. I don't agree with Stefano, I think that posix time is very useful (as I think its ubiquity shows that), and I think that a type that is defined to be posix time would also be very useful. I think that posix time is well suited for the vast majority of use cases. Indeed, there are use cases where you should take into account leap seconds, but those are rare. In practice, a leap second would be presented by the OS as a second that actually takes more than a second. This actually happens all the time without leap seconds - when your computer automatically syncs with ntp, it adjusts the time continuously, so applications will not experience "time bumps". If you want to make sure that the intervals you measure are correct, you should use something like time.monotonic().</div><div><br></div><div>So, most users are not interested in very precise time measurements, but rather in knowing what happened before what, and roughly when. For this, posix time is great - it's very simple, and does the job. In some cases you need to take into account leap seconds, but in those cases, just using the computer clock will not give you the precision you need no matter what - so you'll need specialized software anyway.</div><div><br></div><div>I think that posix time is great, and since it's very easy to make wrong decisions that seem to work until you discover they don't (such as discovering too late that local time won't work when you are not sure of the time zone, or when you switch from DST to winter time), a sane and simple default is important.</div><div><br></div><div>Cheers,</div><div>Noam</div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 12, 2020 at 6:41 PM Matti Picus <<a href="mailto:matti.picus@gmail.com">matti.picus@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 11/12/20 6:04 PM, Stefano Miccoli wrote:<br>
><br>
><br>
>> On 11 Nov 2020, at 18:00, <a href="mailto:numpy-discussion-request@python.org" target="_blank">numpy-discussion-request@python.org</a> <br>
>> <mailto:<a href="mailto:numpy-discussion-request@python.org" target="_blank">numpy-discussion-request@python.org</a>> wrote:<br>
>><br>
>> I propose to add a new type called "timestamp64". It will be a pure <br>
>> timestamp, meaning that it represents a moment in time (as <br>
>> seconds/ms/us/ns since the epoch), without any timezone information.<br>
><br>
> Sorry, but I really don see the usefulness for another time stamping <br>
> format based on POSIX time. Indeed POSIX time is based on a naive <br>
> approximation of UTC and is ambiguous across leap seconds. Quoting <br>
> from Wikipedia <<a href="https://en.wikipedia.org/wiki/Unix_time#Leap_seconds" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Unix_time#Leap_seconds</a>><br>
><br>
> ...<br>
<br>
<br>
In a one-on-one discussion with Noam in a pre-community call (that, how <br>
ironically, we had time for since we both messed up the meeting <br>
time-zone change) we reached the conclusion that the request is to <br>
clarify whether NumPy's datetime64 represents TAI time [0] or POSIX <br>
time, with a preferecne for TAI time. The documentation mentions POSIX <br>
time[1]. As Stefano points out, there is a couple of seconds difference <br>
between POSIX (or Unix) time and TAI time. In practice numpy simply <br>
stores a int64 value to represent the datetime64, and relies on others <br>
to convert it. The leap-second might be getting lost in the conversions. <br>
So it might make sense to clarify exactly how those conversions deal <br>
with the leap-seconds and choose which one we mean when we use <br>
datetime64. Noam please correct me if I am mistaken.<br>
<br>
<br>
Matti<br>
<br>
<br>
[0] <a href="https://en.wikipedia.org/wiki/International_Atomic_Time" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/International_Atomic_Time</a><br>
<br>
[1] <br>
<a href="https://numpy.org/doc/stable/reference/arrays.datetime.html#datetime-units" rel="noreferrer" target="_blank">https://numpy.org/doc/stable/reference/arrays.datetime.html#datetime-units</a><br>
<br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div>