Guido> Proposal for internal representation (also the basis for an Guido> efficient pickle format): Guido> year 2 bytes, big-endian, unsigned (0 .. 65535) ... Guido> - Why is the year unsigned? So memcmp() will do the right thing Guido> for comparing dates (in the same timezone). So the earliest year it can represent is 1BC (or does year == 0 represent some other base year)? One of MAL's desires were that he could use the abstract interface /F defined and remain binary compatible with the current mxDateTime layout. Will your layout work for him? Skip

[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.