I've been reading the Python Date/Time design Wiki, and was wondering how all of those issues were shaking out. Specifically, how final is the current prototype, and what are the outstanding issues yet to be resolved?

I'm beginning to be pretty happy with the prototype; all of the remaining issues are relatively minor IMO. In particular, I'm happy with how the new approach to timezone support is working out, and with the idea of making "naive time" the default, rather than local time. Here's an incomplete list of issues, off the top of my mind: - I'm beginning to have doubts about Effbot's proposed basetime interface, and am tempted to rip it out. - I'm beginning to think that instead of separate types datetime (naive time) datetime and datetimetz (timezone/DST-aware), it might be just as well to have a single type that behaves like the datetimetz prototype: it falls back to naive time when you don't specify a tzinfo argument. We're going to try this in the C version. - Pickling isn't implemented yet. - The date type needs to grow a few methods (to be inherited by datetime of course) to do things like "last Friday of the month". - The datetime methods whose name starts with 'utc' should probably be ripped out. - There are a bunch of methods and constructors that I don't think are very useful. (E.g. the fromordinal() constructors are unused.) - There's no API for conversion between timezones yet. I'm thinking of t.astimezone(tz) which returns an object that represents the same UTC timepoint as t, but has tz for its tzinfo. If t has no tzinfo, (i.e. is naive time), this would do something slightly different: it would create a new object whose year, month, day, hour, minute, second, and microsecond attributes were equal to t's, and whose tzinfo attribute was tz. (I consider that different because naive time doesn't represent a UTC timepoint.) - There's no documentation. (There is an extensive test suite, though.) - Fred's still working on the C version. Among other things, he's got to separate the date and datetime(tz) types. I foresee no roadblocks -- however, it's slow going because other priorities keep popping up (like documenting how to create new-style types in C). --Guido van Rossum (home page: http://www.python.org/~guido/)