[Python-ideas] Date/time literals

[M.-A. Lemburg]

Mark Dickinson wrote:
> On Tue, Jun 1, 2010 at 11:40 PM, Guido van Rossum <guido at python.org> wrote:
>> Also note that there will be no validation possible for future
>> datetimes (and for past dates it would require an up-to-date leap
>> second database).
> 
> It's even worse than that :(.  Complete validation would also require
> timezone knowledge, because leap seconds happen at the same instant
> the world over:  e.g., the leap second that occurred at 23:59:60 UTC
> on 31st December 2008 occurred at 19:29:60 local time in Caracas.   So
> for naive datetime objects validation is going to be difficult.  Given
> that timezone offsets can be an arbitrary number of minutes, the only
> reasonable options as far as I can see would be either *always* to
> accept seconds in the range 0-60, or *always* restrict the range to
> 0-59, as now.  (Well, you could only accept seconds=60 for timestamps
> within 24 hours of midnight on Jun 30 or Dec 31st, but that's fairly
> horrible. :-)
>
> I'm still not convinced that incorrectly accepting some invalid UTC
> times is worse than incorrectly rejecting some (rare) valid UTC times,
> but I'll let it drop for now.

You can use mxDateTime to store such values. I added support for
storing leap seconds long ago, but only for the UTC variants,
not for arbitrary time zones. This was mainly done to support
those values when using mxDateTime as storage container rather
than for calculations (those are all POSIX conform, ie. omit
leap seconds).

Note that most C libs nowadays only support the POSIX
interpretation of time_t values. Those don't include leap seconds:

>>> DateTime(1986,12,31,23,59,59).gmticks()
536457599.0
>>> DateTime(1986,12,31,23,59,60).gmticks()
536457600.0
>>> DateTime(1987,1,1,0,0,0).gmticks()
536457600.0

with leap seconds, you'd get 536457612 for
DateTime(1986,12,31,23,59,59).gmticks().

As a result, conversion to time_t will be lossy.

IIRC, the BSDs were the last to switch off leap second support,
but could be mistaken.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 02 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2010-07-19: EuroPython 2010, Birmingham, UK                46 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/