On Mon, Jun 6, 2011 at 3:47 PM, Mark Dickinson <[email protected]>wrote:
> On Mon, Jun 6, 2011 at 9:24 PM, Mark Wiebe <[email protected]> wrote: > > Sorry for being dense, but: > > > C. Add a metadata item which chooses between "UTC" and "TAI". For seconds > > and finer, converting between UTC and TAI units is safe, and for minutes > and > > coarser, is unsafe. UTC involves leap-seconds > > This bit I understand, but: > > > 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, you end up at second 60 in a minute which has only 60 seconds, and you have to fall back to second 59 or forward to second 0 of the next minute. Also, if you add a minute which should land where a leap-second was removed, you have to fall back to second 58 or second 0 of the next minute. > [...] > > Does this design sound reasonable to people? > > Python's datetime and timedelta types use POSIX time (i.e., just > pretend that leap seconds don't exist and hope that everything works > out okay). Would this cause problems when converting between Python > and NumPy types? Converting from the Python type to the NumPy type has a problem for removed leap-seconds (of which there are currently none), and converting from the NumPy type to the Python type has a problem for added leap-seconds. To allow for round-tripping to/from python objects, I think I would just make it return the underlying 64-bit number instead of a Python datetime object. This is also what it does for years outside of the range Python accepts. > I guess part of the point of this work is that with > full datetime support in NumPy the need for such conversions would be > relatively rare, so maybe there's no real problem here. > Yeah, as long as the calendar-related API is sufficient, I think that's true. But having thought quite hard about some of these issues for Python's > datetime module recently, I'm sceptical that leap second support is > really that valuable, and fear that having it turned on by default > will cause nasty surprises for those who have no need to think about > leap seconds and write code that assumes that a minute has 60 seconds. > I think that by having some default ambiguity-resolution rules for leap seconds, things will generally work out as people expect. 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. I found it disconcerting that datetime.datetime.now() returns local time with no time zone indication on it. Here's how I've resolved that issue in NumPy: >>> datetime.datetime.now() datetime.datetime(2011, 6, 6, 17, 10, 32, 444658) >>> np.datetime64('now') numpy.datetime64('2011-06-06T17:10:41.000000-0500','us') Cheers, Mark
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
