[Numpy-discussion] timezones and datetime64

[Nathaniel Smith]

On Thu, Apr 4, 2013 at 6:06 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Thu, Apr 4, 2013 at 11:01 AM, Chris Barker - NOAA Federal
> <chris.barker at noaa.gov> wrote:
>>
>> On Wed, Apr 3, 2013 at 6:02 PM, Mark Wiebe <mwwiebe at gmail.com> wrote:
>> > One problem with trying to give technically correct answers for the
>> > UTC/Posix format is that it can't actually represent the leap-second, so
>> > a
>> > datetime64 + timedelta64 could produce an unrepresentable moment in
>> > time.
>>
>> I'm a bit confused by that -- how it it different than leap-days?
>
>
> There is a rule for leap days, one knows ahead of time when they will occur.

That is true, but it's not the issue with POSIX. The problem with
POSIX is that when a leap second is inserted, you end up with two
different physical spans of time that get assigned exactly the same
POSIX time value. Imagine if we represented days-of-the-year by
integers in the range [0, 365), and the standard said that all years
must have exactly 365 days. When a leap year happened, we'd have
nowhere to put Feb. 29. So instead we'd just have to have Feb. 28
twice. That's how POSIX handles leap seconds. (Also, if we ever get a
deleted leap second -- which has never happened -- then there will be
an integer value that time_t can take, but that does not correspond to
any actual physical moment in time.)

Leap second records are recorded in the Olson tz database, so in
principle they should be available on most systems, and without us
having to take responsibility for keeping the database up to date. I
don't know if pytz makes this available.

-n