[Python-Dev] proposal: add basic time type to thestandardlibrary (original) (raw)

Stephan Richter srichter@cbu.edu
Sun, 10 Feb 2002 13:08:09 -0600

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