[Python-Dev] proposal: add basic time type to thestandardlibrary

[Stephan Richter]

>As I explained my reply, most of these intervals are not needed
>as *base types*. You can easily model them on top of the two
>types I have in mxDateTime. Some may not like this model because it
>comes from a more mathematical point of view, but in reality it
>works quite nicely and simplifies the API structure significantly.
>
>A time interval is basically just an amount of seconds, nothing more.
>There's no need to have 4 different types to wrap a single
>double ;-)

Well, this is an okay representation, if you want to do a lot of math and 
use it mainly for this reason. On the other hand it might be fairly 
expensive, if I always want to extract components. In fact, only 10% of my 
usage requires mathematical operations. Most of the time I get the interval 
out of the database and want to simply display it (localized), such as in 
calendars.

> >  >>> import DateTime
> >  >>> date = DateTime.parseDateTime('2.1.2001')
> >  >>> type(date).__name__
> > Date
> >  >>> time = DateTime.parseDateTime('12:00:00')
> >  >>> type(time).__name__
> > Time
> >  >>> datetime = DateTime.parseDateTime('2.1.2001 12:00:00')
> >  >>> type(datetime).__name__
> > DateTime
>
>Just think of all the possible combinations you have in operations
>like '+', '-' and comparisons. You don't want to go down this
>road...

Well, but again, 90% of the time I do not need to do any manipulation 
whatsoever. For this reason you would have time stamps or you know (because 
you used this type) that it will be less efficient to do '+' and '-' with 
DateTime objects, since it does need some more conversions.

>Uhm, where did you get the impression that I want all the world
>to use mxDateTime :-? I wrote it for use in mxODBC since at the time
>there was no DateTime type around which could handle dates prior
>to 1970. As a result, mxDateTime was written to provide everything
>you need for database interfacing. That's also the reason why there
>is no time zone support in mxDateTime's base types: databases
>don't have time zone support built into their date/time types
>either (and for a good reason: time zones are better handled at
>application level).

Well, back then (when I wrote the mail) I thought so. But now I see the 
limitations and have a better idea what people need; hence this proposal. 
For the same reason you say mxDateTime is not good for everything we need a 
solution that works for more situations.

>You really just want to support one way for the type constructor
>(broken down numbers). All other possibilities can be had via
>factory functions.

Probably so.  I will have to think about it some more and look at some 
applications.

> > But by default:
> >
> >  >>> DateTime.parseDateTime('03/02/01')
> > March 2, 2001
> >  >>> DateTime.parseDateTime('03.02.01')
> > February 3, 2001
>
>You can do all this with Parser module in mxDateTime. It allows
>you to specify a list of parsers to try and in which order
>to try them. Chuck Esterbrook has kept me working on it for
>quite some time, so it should be very complete by now :-)
>
>For more specific (and strict) formats, there are two other
>modules ISO and ARPA which can handle the respective
>formats used in Internet standards.

Right. And I am not saying that we will not reuse some of the mxDateTime or 
the Zope DateTime code. I certainly do not want to reimplement stuff that 
already works very well. Also, we need to support I18N, which means the 
module needs to understand things like "February", but also "Februar" if 
the German locale was requested.

I have no desire to compete with the mxDateTime implementation. I want to 
look at some of the solutions out there and take the best from everyone and 
provide a module that will suit 95-100% of the people. For several reasons, 
which I tried to point out in my mails, mxDateTime or Zope's Datetime in 
its current states is not suitable.

Regards,
Stephan

--
Stephan Richter
CBU - Physics and Chemistry Student
Web2k - Web Design/Development & Technical Project Management