[Zope] - Some DateTime behaviors I just don't understand

[Jim Fulton]

skip@calendar.com wrote:
> 
> I tried:
> 
>     dt = DateTime.DateTime(time.time())
>     dt.timeTime()
> 
> and got just what I expected:
> 
>     915677129.19
> 
> I then tried
> 
>     dt = DateTime.DateTime(0.0)
>     dt.timeTime()
> 
> and got a traceback:
> 
>     Traceback (innermost last):
>       File "<stdin>", line 1, in ?
>       File "DateTime/DateTime.py", line 874, in timeTime
>         raise self.DateTimeError,'No time module compatible time to return'
>     DateTimeError: No time module compatible time to return
> 
> Surely 0.0 is a valid time module compatible time:

It is, but the DateTime constructor doesn't interpret it as
such.  It interprets it as the number of days since Jan 1, 1901.

Jan 1, 1901 can't be converted to a time time.

>     time.gmtime(0.0)
>     (1970, 1, 1, 0, 0, 0, 3, 1, 0)
> 
> Can I not initialize a DateTime object to the Unix epoch?

Currently, you have to:

  apply(DateTime,time.gmtime(0)[:6])

or:

  apply(DateTime,time.localtime(0)[:6])


> I tried several
> multiples of 10.0 and didn't avoid the traceback until I tried
> 
>     dt = DateTime.DateTime(100000.0)
> 
> which is somewhat more than one day more recent than gmtime(0.0).

Right,
 
> There's apparently some magnitude-dependent interpretation of single numeric
> initializers, but the documentation file in the package is unclear on how it
> distinguishes between the two interpretations:
> 
>     A DateTime object is returned that represents either the gmt value of
>     the time.time() float represented in the local machine's timezone, or
>     that number of days after January 1, 1901. Note that the number of days
>     after 1901 need to be expressed from the viewpoint of the local
>     machine's timezone. A negative argument will yield a date-time value
>     before 1901.

Right.
 
> While horsing around some more, I got some other strange behavior as well:
> 
>     >>> time.gmtime(24*60*60)
>     (1970, 1, 2, 0, 0, 0, 4, 2, 0)
>     >>> dt = DateTime.DateTime(24*60*60)
>     >>> dt.timeTime()
>     86400
>     >>> dt = DateTime.DateTime(24*60*50)
>     >>> dt.timeTime()
>     72000
>     >>> dt = DateTime.DateTime(24*60*40)
>     >>> dt.timeTime()
>     57600
>     >>> dt = DateTime.DateTime(24*60*30.0)
>     Traceback (innermost last):
>       File "<stdin>", line 1, in ?
>       File "DateTime/DateTime.py", line 513, in __init__
>         s=(_j-int(_j))*86400.0
>     OverflowError: float too large to convert
>     >>> dt.timeTime()
>     57600
>     >>> dt = DateTime.DateTime(24*60*30)
>     Traceback (innermost last):
>       File "<stdin>", line 1, in ?
>       File "DateTime/DateTime.py", line 513, in __init__
>         s=(_j-int(_j))*86400.0
>     OverflowError: float too large to convert
> 
> Why would I be getting overflow errors as the numbers got smaller?

You don't want to know. ;)

The problem is that DateTime wants to support
offsets in seconds from the epoc *and* offsets
in days from 1901-01-01.  This approach is flawed.
(It results from some interface baggage from 
some older date-time implementations of mine.)

I'm inclined to change DateTime to only expect
epoch offsets in seconds when a single
numeric argument is given.  This will be changed
in the next release.

Jim


--
Jim Fulton           mailto:jim@digicool.com
Technical Director   (540) 371-6909              Python Powered!
Digital Creations    http://www.digicool.com     http://www.python.org

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.