[Python-Dev] proposal: add basic time type to the standard library

[Tim Peters]

[Guido van Rossum]
> ...
> My plan is to create a standard timestamp object in C that can be
> subclassed.

As an earlier msg said, "details, details".  Any chance of setting up a Wiki
for this project?  I'd also suggest writing the test suite first, because I
suspect that asking people to submit tests is the only effective way to
tease out their hidden assumptions and requirements.

> ...
> as well as conversions to and from the two currently most popular time
> representations used by the time module: posix timestamps in UTC

Those are of type time_t, and that's opaque (maybe of a floating or integral
type, depending on platform).  What's the type in Python?  By "posix"
timestamps I assume you mean to imply at least "no leap seconds".  Note that
POSIX/SUS still doesn't require that time_t "work" beyond 2038, so we have
to define what happens then on platforms using stupid time_t.  What about
years before 1970?  POSIX/SUS still leaves that undefined, and also time()
values < 0, except for (time_t)-1 (which means "error" from time() --
although no possible errors are defined for time()!).

> and 9-tuples in local time.

Too depressing to even consider one-by-one <wink>.

> There will be a C API.

Most of the questions above were about that.

> Proposal for internal representation (also the basis for an efficient
> pickle format):
>
> year	 2 bytes, big-endian, unsigned (0 .. 65535)

Do you intend to treat October 1582 as a magical month?  Note that to the
chagrin of calendar weenies, ECMAScript explicitly refused to, pretending
instead that the current Gregorian calendar always was, and always will be,
in effect.  I'm +1 on us doing likewise.  In part, the more uniform we make
this abstraction, the more good it will do people who want some insane
<wink> sort of date gimmick instead (if our rules are regular, they can
adjust our results by injecting their favorite insanities, without having to
first subtract out our insanities).

> month	 1 byte
> day	 1 byte
> hour	 1 byte
> minute	 1 byte
> second	 1 byte
> usecond	 3 bytes, big-endian
> tzoffset 2 bytes, big-endian, signed (in minutes, -1439 .. 1439)

I've rarely seen docs for any time gimmick that made it *clear* whether the
time zone offset needs to be added to, or subtracted from, the rest of the
fields, to get the corresponding UTC point.  Plain "offset" is plainly
ambiguous.  Authors think they're being clear using "ahead" or "behind"
instead, but at least twice I've seen those used in a backwards sense too.
Which direction do you have in mind?  Does it matter?  Maybe we should add a
flag bit to say which direction is intended <wink>.

Overall, I like it -- it's just the details, details, details that make this
kind of thing a drag before it's real.