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

[M.-A. Lemburg]

Fredrik Lundh wrote:
> 
> mal wrote:
> 
> > > Doesn't the proposal sort of imply time-zone
> > > awareness of some kind? Or does it simply imply
> > > UT storage?
> >
> > I tried that in early version of mxDateTime -- it fails
> > badly.
> 
> can you elaborate?

First of all, the C lib only support UTC and local time,
so you don't really have a chance of correctly converting
a non-local time using a different time zone in either local
time or UTC: there simply are no C APIs you could use and
the problems which DST and leap seconds introduces are
no fun at all (they are fun to read though: figuring out
the various DST switch times is an adventure -- just have
a look at the C lib's DST files).

The next problem is that the C lib only provides APIs
for conversion from local time to UTC, but not UTC to
local time. There is an API called timegm() for this
on some platforms, but its non-standard.

As a result, making UTC the default won't allow you
to safely represent the datetime value in local time.

A third obstacle is typcial user assumptions: users simply
assume local time and it's hard to tell them otherwise
(people have very personal feelings about date and time 
for some reason...).

> > > Does this imply leap second hell, or will we
> > > simply be vague about expectations?
> >
> > The type will store a fixed point in time, so why
> > worry about leap seconds (most system's don't support these
> > anyway and if they do, the support is usually switched off per
> > default) ?
> 
> the updated proposal adds __hash__ and __cmp__, and
> the following (optional?) operations:
> 
>     deltaobject = timeobject - timeobject
>     floatobject = float(deltaobject) # fractional seconds
>     timeobject = timeobject + integerobject
>     timeobject = timeobject + floatobject
>     timeobject = timeobject + deltaobject
> 
> note that "deltaobject" can be anything; the abstract type
> only says that if you manage to subtract one time object from
> another one of the same type, you get some object that you
> can 1) convert to a float, and 2) add to another time object.
> 
> vague, but pretty useful.

Indeed :-)
 
> > > I'd also like to see simple access methods for year,
> > > month, day, hours, minutes, and seconds, with date parts
> > > being one based and time parts being zero based.
> >
> > In the abstract base type ?
> 
> Q. does mxDateTime provide separate accessors for individual
> members?

Yes, it provides access to these in form of attributes.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/