[Python-ideas] Date/time literals

[Guido van Rossum]

On Tue, Jun 1, 2010 at 2:00 AM, Mark Dickinson <dickinsm at gmail.com> wrote:
> On Sun, May 30, 2010 at 9:28 AM, Masklinn <masklinn at 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)