[Python-Dev] Status of Python Date/Time proposal?

[Guido van Rossum]

> 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/)