[Numpy-discussion] dealing with datetime UTC vs linear time

Mark Dickinson mdickinson at enthought.com
Tue Jun 7 03:29:52 EDT 2011


On Mon, Jun 6, 2011 at 11:12 PM, Mark Wiebe <mwwiebe at gmail.com> wrote:
> On Mon, Jun 6, 2011 at 3:47 PM, Mark Dickinson <mdickinson at enthought.com>
>> On Mon, Jun 6, 2011 at 9:24 PM, Mark Wiebe <mwwiebe at gmail.com> wrote:
>> > and an ambiguity-resolution in the few cases that need it,
>>
>> Where does the ambiguity come from?  (Assuming we're not more than 6
>> months into the future.)  There would be ambiguity with POSIX time,
>> but doesn't UTC manage to specify any point in time unambiguously?
>
> If you add one minute to an added leap-second [...]

Ah, yes. I wasn't thinking as far ahead as arithmetic.  Thanks.

> [...]
> I think that by having some default ambiguity-resolution rules for leap
> seconds, things will generally work out as people expect.

Yes, I expect that's true.

> On the other hand,
> with POSIX time, anybody that wants things precise with respect to
> leap-seconds is automatically excluded. The potential surprises from
> leap-seconds seem milder than the surprises from time zones and the
> multitude of possible calendars out there.

Well, except that people are quite used to having to deal with time
zones / DST / etc. as a matter of course, and that the surprises from
time zones are likely to bite earlier (i.e., with luck, during
development rather than after deployment).  I'd argue that the rarity
of leap seconds (both in terms of ratio of leap seconds to non-leap
seconds, and in terms of the number of applications that really have
to care about leap seconds) would make for late-surfacing bugs in
application code;  so I'd personally prefer to see an 'opt-in' version
of leap second support, rather than 'opt-out'.  Still, I'm largely
guessing here, so take with a large pinch of salt.

(If this were a Python mailing list, I'd trot out 'Practicality Beats
Purity' from the Zen here.)

> I found it disconcerting that
> datetime.datetime.now() returns local time with no time zone indication on
> it.

Yes, I agree that that's disturbing.  datetime support for time zones
isn't the best.

Thanks for the detailed response.  I'll go back to lurking now.

Mark



More information about the NumPy-Discussion mailing list