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.

>>import time
t = time.strptime("Mar 30, 2007 2:43:32 am", "%b %d, %Y %I:%M:%S
%p")
time.mktime(t)

1175215412.0

>>t = time.strptime("Mar 30, 2008 2:43:32 am", "%b %d, %Y %I:%M:%S
%p")
time.mktime(t)

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

>>>

robert

[Wojtek Walczak]

Dnia 7 Aug 2008 18:40:10 GMT, Robert Latest napisa³(a):

>>>t = time.strptime("Mar 30, 2008 2:43:32 am", "%b %d, %Y %I:%M:%S
%p")
time.mktime(t)

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

>>>>

time module is written in C. time.mktime() function is actually
only a wrapper for mktime(3) and it also has its limits. Better
use datetime module instead.

--
Regards,
Wojtek Walczak,
http://www.stud.umk.pl/~wojtekwa/

[M.-A. Lemburg]

On 2008-08-07 20:40, Robert Latest wrote:

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.

>>>import time
t = time.strptime("Mar 30, 2007 2:43:32 am", "%b %d, %Y %I:%M:%S
%p")
time.mktime(t)

1175215412.0

>>>t = time.strptime("Mar 30, 2008 2:43:32 am", "%b %d, %Y %I:%M:%S
%p")
time.mktime(t)

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:

>>from mx.DateTime import DateTimeFrom
DateTimeFrom("Mar 30, 2007 2:43:32 am")

<mx.DateTime.DateTime object for '2007-03-30 02:43:32.00' at 2b41dd704d40>

>>DateTimeFrom("Mar 30, 2008 2:43:32 am")

<mx.DateTime.DateTime object for '2008-03-30 02:43:32.00' at 2b41ddd397c0>

>>DateTimeFrom("Mar 30, 2007 2:43:32 am").ticks()

1175215412.0

>>DateTimeFrom("Mar 30, 2008 2:43:32 am").ticks()

1206841412.0

http://www.egenix.com/products/pytho...se/mxDateTime/

--
Marc-Andre Lemburg
eGenix.com

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

>>Python/Zope Consulting and Support ... http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

__________________________________________________ ______________________

:::: 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]

On Aug 8, 4:40 am, Robert Latest <[e-mail]:

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.

>>import time
t = time.strptime("Mar 30, 2008 2:43:32 am", "%b %d, %Y %I:%M:%S %p")
time.mktime(t)

1206805412.0

>>t

(2008, 3, 30, 2, 43, 32, 6, 90, -1)

>>^Z

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.

>>import time
t = time.strptime("Mar 30, 2008 2:43:32 am", "%b %d, %Y %I:%M:%S %p")
time.mktime(t)

1206805412.0

>>t

(2008, 3, 30, 2, 43, 32, 6, 90, -1)

>>>

>
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.

Type "help", "copyright", "credits" or "license" for more information.>>import time

>t = time.strptime("Mar 30, 2007 2:43:32 am", "%b %d, %Y %I:%M:%S
%p")
time.mktime(t)

1175215412.0

>t = time.strptime("Mar 30, 2008 2:43:32 am", "%b %d, %Y %I:%M:%S
%p")
time.mktime(t)

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

[Tim Roberts]

Robert Latest <bo*******@yahoo.comwrote:

>
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.

>...

>>>t = time.strptime("Mar 30, 2008 2:43:32 am", "%b %d, %Y %I:%M:%S
%p")
time.mktime(t)

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?
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[Robert Latest]

Tim Roberts wrote:

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