Re: [Zope] Help with DateTime.earliestTime()
Eric Thomas wrote at 2007-8-25 07:18 -0500:
>I've been having a site problem that I've tracked down to DateTime. Simply
>enough, the code snippets below both try to add 31 days to the first day in
>October. I'm expecting this to result in the first day of November.
>
>Good Example:
>
from DateTime import DateTime
start=DateTime('2005/10/01 01:00:00 GMT-5')
print start
>2005/10/01 01:00:00 GMT-5
earlyStart=start.earliestTime()
print earlyStart
>2005/10/01
print earlyStart+31
>2005/11/01
>
>Bad Example: (Here's the problem)
>
from DateTime import DateTime
start=DateTime('2005/10/01 01:00:00 US/Central')
print start
>2005/10/01 01:00:00 US/Central
earlyStart=start.earliestTime()
print earlyStart
>2005/10/01
print earlyStart+31
>2005/10/31 23:00:00 US/Central
>
>I've confirmed this occurs with several of the US/ timezones (US/Pacific,
>US/Alaska, etc)
This looks like a daytime saving problem:
With daytime saving, the clock often is put back for an hour
at the last samday in october
The "DateTime" implementation could avoid this
*if* the arithmetic would only accept
"int" (then it would be very likely that you only want to modify
the day but not hours, minutes and seconds). But the arithmetic
accepts "float" and that necessitates some surprises with
time discontinuities (such as daytime saving switches).
>
>Can anyone help me figure out why the resulting date is coming up 1 hour
>short of the expected 2005/11/01 ?
>
>Thanks!
>
>Eric
>I've been having a site problem that I've tracked down to
>DateTime. Simply enough, the code snippets below both try to add 31 days
>to the first day in October. I'm expecting this to result in the
>first day of November.
>
>
>Good Example:
>
from DateTime import DateTime>>>
>start=DateTime('2005/10/01 01:00:00 GMT-5')>>> print
>start2005/10/01 01:00:00 GMT-5>>>
>earlyStart=start.earliestTime()
print earlyStart2005/10/01>>> print
>earlyStart+312005/11/01
>
>Bad Example: (Here's the problem)
from DateTime import DateTime>>>
>start=DateTime('2005/10/01 01:00:00 US/Central')>>> print
>start2005/10/01 01:00:00 US/Central>>>
>earlyStart=start.earliestTime
>()>>> print earlyStart2005/10/01>>> print
>earlyStart+312005/10/31 23:00:00 US/Central
>I've confirmed this occurs with several of the US/ timezones
>(US/Pacific, US/Alaska, etc)
>Can anyone help me figure out why the resulting date is coming up 1 hour
>short of the expected 2005/11/01 ?
>Thanks!
>Eric
>
>
--
Dieter
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: Help with DateTime.earliestTime()
Dieter Maurer <[EMAIL PROTECTED]> writes:
>
> Eric Thomas wrote at 2007-8-25 07:18 -0500:
> >I've been having a site problem that I've tracked down to DateTime. Simply
> >enough, the code snippets below both try to add 31 days to the first day in
> >October. I'm expecting this to result in the first day of November.
> >
> >Good Example:
> >
> from DateTime import DateTime
> start=DateTime('2005/10/01 01:00:00 GMT-5')
> print start
> >2005/10/01 01:00:00 GMT-5
> earlyStart=start.earliestTime()
> print earlyStart
> >2005/10/01
> print earlyStart+31
> >2005/11/01
> >
> >Bad Example: (Here's the problem)
> >
> from DateTime import DateTime
> start=DateTime('2005/10/01 01:00:00 US/Central')
> print start
> >2005/10/01 01:00:00 US/Central
> earlyStart=start.earliestTime()
> print earlyStart
> >2005/10/01
> print earlyStart+31
> >2005/10/31 23:00:00 US/Central
> >
> >I've confirmed this occurs with several of the US/ timezones (US/Pacific,
> >US/Alaska, etc)
>
> This looks like a daytime saving problem:
>
> With daytime saving, the clock often is put back for an hour
> at the last samday in october
>
> The "DateTime" implementation could avoid this
> *if* the arithmetic would only accept
> "int" (then it would be very likely that you only want to modify
> the day but not hours, minutes and seconds). But the arithmetic
> accepts "float" and that necessitates some surprises with
> time discontinuities (such as daytime saving switches).
>
> >
> >Can anyone help me figure out why the resulting date is coming up 1 hour
> >short of the expected 2005/11/01 ?
> >
> >Thanks!
> >
> >Eric
I've submitted this as a zope bug and I agree that it looks like a daytime
saving problem. The problem was tiggered nightly by a Google bot hitting
various dates on my site's calendar.
Even more interesting is that the seconds, milliseconds, and timezone stored
within the DateTime are correct after the addition. So, if I compare the two
results from the examples I gave using DateTime.isEqualTo(), the answer is
True. This really creates a lot of opportunity for error.
To work around this, I've modified the addition so that instead of adding 1
day, it adds 1.5 days. This extra half a day is removed by the
theDateTime.earliestTime() call but is enough to overcome the DST addition
problem. Ugly hack.
Thanks all.
- Eric
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Help with DateTime.earliestTime()
--On 26. August 2007 19:12:18 + Eric <[EMAIL PROTECTED]> wrote:
Dieter Maurer <[EMAIL PROTECTED]> writes:
Eric Thomas wrote at 2007-8-25 07:18 -0500:
> I've been having a site problem that I've tracked down to DateTime.
> Simply enough, the code snippets below both try to add 31 days to the
> first day in October. I'm expecting this to result in the first day
> of November.
>
> Good Example:
>
from DateTime import DateTime
start=DateTime('2005/10/01 01:00:00 GMT-5')
print start
> 2005/10/01 01:00:00 GMT-5
earlyStart=start.earliestTime()
print earlyStart
> 2005/10/01
print earlyStart+31
> 2005/11/01
>
> Bad Example: (Here's the problem)
>
from DateTime import DateTime
start=DateTime('2005/10/01 01:00:00 US/Central')
print start
> 2005/10/01 01:00:00 US/Central
earlyStart=start.earliestTime()
print earlyStart
> 2005/10/01
print earlyStart+31
> 2005/10/31 23:00:00 US/Central
>
> I've confirmed this occurs with several of the US/ timezones
> (US/Pacific, US/Alaska, etc)
This looks like a daytime saving problem:
With daytime saving, the clock often is put back for an hour
at the last samday in october
The "DateTime" implementation could avoid this
*if* the arithmetic would only accept
"int" (then it would be very likely that you only want to modify
the day but not hours, minutes and seconds). But the arithmetic
accepts "float" and that necessitates some surprises with
time discontinuities (such as daytime saving switches).
>
> Can anyone help me figure out why the resulting date is coming up 1
> hour short of the expected 2005/11/01 ?
>
> Thanks!
>
> Eric
I've submitted this as a zope bug and I agree that it looks like a
daytime saving problem. The problem was tiggered nightly by a Google
bot hitting various dates on my site's calendar.
Even more interesting is that the seconds, milliseconds, and timezone
stored within the DateTime are correct after the addition. So, if I
compare the two results from the examples I gave using
DateTime.isEqualTo(), the answer is True. This really creates a lot of
opportunity for error.
If you can: use Python's datetime module. DateTime is broken in many ways.
-aj
pgpOtr6LoOYCd.pgp
Description: PGP signature
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
