mktime overflow in March 2008?

[Robert Latest]

Here's what happens on my Windows machine (Win XP / Cygwin) at work.
I've googled a bit about this problem but only found references to
instances where people referred to dates before the Epoch.

Of course at home on my Linux box everything works.

I know that everything has its limits somewhere, but I've never
heard of March 2008 being a problem.

Tomorrow I'm going to write a test loop that shows me the exact last
second that mktime is going to be able to handle. Sort of like the way
Calvin's father explains the weight limit specification of bridges.

I wonder if the datetime module is any better, considering that under
the hood it probably uses the same C library functions.

I like to stick with the "seconds since..." approach because I need to
store millions of dates/times efficiently in a sqlite database.

$ python
Python 2.5.1 (r251:54863, May 18 2007, 16:56:43)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):

robert

 

[M.-A. Lemburg]

Here's what happens on my Windows machine (Win XP / Cygwin) at work.
I've googled a bit about this problem but only found references to
instances where people referred to dates before the Epoch.

Of course at home on my Linux box everything works.

I know that everything has its limits somewhere, but I've never
heard of March 2008 being a problem.

Tomorrow I'm going to write a test loop that shows me the exact last
second that mktime is going to be able to handle. Sort of like the way
Calvin's father explains the weight limit specification of bridges.

I wonder if the datetime module is any better, considering that under
the hood it probably uses the same C library functions.

I like to stick with the "seconds since..." approach because I need to
store millions of dates/times efficiently in a sqlite database.

$ python
Python 2.5.1 (r251:54863, May 18 2007, 16:56:43)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: mktime argument out of range

Well, you could use the parser in mxDateTime:
1206841412.0

http://www.egenix.com/products/python/mxBase/mxDateTime/

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Aug 07 2008)________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX 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

 

[John Machin]

Here's what happens on my Windows machine (Win XP / Cygwin) at work.
I've googled a bit about this problem but only found references to
instances where people referred to dates before the Epoch.

Of course at home on my Linux box everything works.

And of course using the official versions of Python for Windows
everything works:

C:\junk>\python25\python
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
C:\junk>\python24\python
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.

I know that everything has its limits somewhere, but I've never
heard of March 2008 being a problem.

Tomorrow I'm going to write a test loop that shows me the exact last
second that mktime is going to be able to handle. Sort of like the way
Calvin's father explains the weight limit specification of bridges.

I wonder if the datetime module is any better, considering that under
the hood it probably uses the same C library functions.

Don't wonder; try it out; look at the source.

I like to stick with the "seconds since..." approach because I need to
store millions of dates/times efficiently in a sqlite database.

$ python
Python 2.5.1 (r251:54863, May 18 2007, 16:56:43)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin

There's your problem.

 

[Tim Roberts]

Here's what happens on my Windows machine (Win XP / Cygwin) at work.
I've googled a bit about this problem but only found references to
instances where people referred to dates before the Epoch.

Of course at home on my Linux box everything works.

I know that everything has its limits somewhere, but I've never
heard of March 2008 being a problem.

Tomorrow I'm going to write a test loop that shows me the exact last
second that mktime is going to be able to handle. Sort of like the way
Calvin's father explains the weight limit specification of bridges.

That's what it's going to sound like when I ask my question.

...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: mktime argument out of range

What time zone are you in? March 30, 2008, was a Sunday. If that happened
to be the date your country transitioned to summer time, then the hour
between 2 AM and 3 AM would not exist.

Does it work if you use 3:43 AM?

 

[Robert Latest]

What time zone are you in? March 30, 2008, was a Sunday. If that happened
to be the date your country transitioned to summer time, then the hour
between 2 AM and 3 AM would not exist.

Does it work if you use 3:43 AM?

Actually you're right; I'm in Middle Europe, and DST was started on
March 30, 2am. I need to check this.

robert