I've given the UTC leap-second issue a bit of thought, and here are some related requirements I've come up with:
1. The underlying data representation of datetime64 should be linearly related to time. 2. Default calendar functionality should be based on ISO 8601, and by reference be in UTC 3. It should be possible to unambiguously specify a time at any point in the past or the future, and get such a representation back from NumPy. One problem trying to resolve these requirements with respect to UTC is that either the underlying time has jump discontinuities, like in POSIX time_t, or minutes, hours, days, and weeks are sometimes one second longer or shorter. Additionally, it's not possible in general to specify UTC times with second resolution 6 or more months in advance. Here's what I propose NumPy's datetime do: A. Use a linear time representation, point 1. Conversion to/from ISO 8601 strings thus requires leap-second knowledge. B. Extend ISO8601 with a "TAI" suffix which is just like "Z" but has no leap-seconds and is 34 seconds ahead of an equivalent "Z" time at the present. This satisfies point 3. 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 and an ambiguity-resolution in the few cases that need it, while in TAI everything is linear. Local time zone-based formatting is only available for UTC datetimes. By default, all units will be UTC, but either TAI or UTC can be specified like 'M8[D:TAI]' or 'M8[h:UTC]'. Does this design sound reasonable to people? Cheers, Mark
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
