On Tue, Jun 1, 2010 at 2:00 AM, Mark Dickinson <dickinsm@gmail.com> wrote:
On Sun, May 30, 2010 at 9:28 AM, Masklinn <masklinn@masklinn.net> wrote:
datetime does have a bunch of issues and limitations which I believe soon become harmful when doing serious date/calendaring works (which I don't claim to do, but I've seen colleagues in serious trouble due to both personal lack of knowledge in the field and issues with datetime itself): it only supports a gregoriany calendar for instance, it's horrendous in dealing with timezones, some methods are pretty much broken, constructor refuses "24" as an hour value, blows up on positive leap seconds)…
Are there tracker issues open for all these problems? It not, please would you consider opening some? The datetime module has recently been getting a lot more attention than it used to, thanks largely to the efforts of Alexander Belopolsky, so I think opening relevant tracker issues would be worthwhile.
Some of the issues you mention look like easy fixes (e.g., allowing positive leap seconds, allowing '24:00:00' as a valid time).
Whoa, the datetime module was explicitly designed not to support leap seconds. This matches the POSIX standard for timestamps, which, although commonly explained as "seconds since 1/1/1970 UTC" doesn't count leap seconds either (it would make the conversions between timestamps and date/time objects horribly complicated since leap seconds are not determined by an algorithm). This is all intentional, since leap seconds are designed to be ignorable by most people except a few communities like astronomers, who have their own clocks.
The API problems for timezones look a little bit more serious.
Isn't the main problem that no timezone implementations are provided by the standard library? There is a reason for that too (although we should at least have UTC in the stdlib).
What are the use-cases for non-Gregorian calendars, and why do you think the datetime module should support them? This seems like a specialist need to me.
I believe the main use case is compatibility with Java, which does support other calendars. Not a big motivation for me. :-)
And which methods are 'pretty much broken'?
If you want to see progress on these issues, please do open some bugtracker issues. Or if open issues already exist, it might be worth pinging them.
In general I would hesitate about attempts to "fix" "problems" with the datetime module that were carefully considered API properties when the design was first made. The only problems that I currently take seriously are issues with dates before 1900, which IIRC stem from reliance on C stdlib functions for manipulating time structs. -- --Guido van Rossum (python.org/~guido)