[Numpy-discussion] dealing with datetime UTC vs linear time
Tue Jun 7 08:09:36 CDT 2011
On Tue, Jun 7, 2011 at 2:29 AM, Mark Dickinson <email@example.com>wrote:
> On Mon, Jun 6, 2011 at 11:12 PM, Mark Wiebe <firstname.lastname@example.org> wrote:
> > 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.
This is what I'm leaning towards now, too. Instead of UTC vs TAI, I think
it's POSIX vs TAI and just for the datetime type, not the timedelta. So I'm
changing my proposal to M8[s:POSIX] and M8[s:TAI] as the dtypes, with POSIX
being the default if nothing is specified.
(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
> > 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.
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion