[Zope] Re: Help with DateTime.earliestTime()

2007-08-28 Thread Maurits van Rees
J Cameron Cooper, on 2007-08-27:
 Maurits van Rees wrote:
 Hm, that should probably be except DateTime.DateTime.DateError but
 there is not really anything else that can go wrong here.

 A ConflictError can go wrong here, which is an additional and important 
 reason not to have a bare except. There are good reasons without that, 
 as well.

Well, you are right of course.  I fixed it.  Thanks for keeping me
sharp. :)

-- 
Maurits van Rees | http://maurits.vanrees.org/ [NL]
Work | http://zestsoftware.nl/
Do not worry about your difficulties in computers,
 I can assure you mine are still greater.

___
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()

2007-08-27 Thread Eric Thomas
On 8/27/07, Dieter Maurer [EMAIL PROTECTED] wrote:

 Andreas Jung wrote at 2007-8-26 21:23 +0200:
  ...
 If you can: use Python's datetime module. DateTime is broken in many
 ways.

 If it handles daytime saving and addition by some float days -- it will
 not have any chance...

 If it does not handle daytime saving -- then it misses an essential
 use case...

 Some problems come from the complexity of the real world and
 not from a particular implementation



 --
 Dieter


In this case it seems that the complexity is being added by the DateTime
implementation.  When given an int number of days and a DateTime that has no
time element, DateTime should not convert everything down to seconds and
account for DST that happens to occur during the period.

When adding days + days, I'd expect to get a result that only considers
days; not DST.
So I agree with your earlier post that DateTime should treat int and float
addition differently.  It should also probably look at the DateTime and
revert to integer math if there is no time element present.

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


[Zope] Re: Help with DateTime.earliestTime()

2007-08-27 Thread J Cameron Cooper

Maurits van Rees wrote:

Eric, on 2007-08-26:
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.


I had the same problem once in the eXtremeManagement Plone product.
For a monthly overview I needed to do something for every day of the
month.  I worked around it with the code below.

day = 1
date = DateTime(2007, 10, 1) # 1 October 2007
while True:
# skipped some lines irrelevant to the DateTime problem
day += 1
try:
date = DateTime(self.year, self.month, day)
except:
break

Hm, that should probably be except DateTime.DateTime.DateError but
there is not really anything else that can go wrong here.


A ConflictError can go wrong here, which is an additional and important 
reason not to have a bare except. There are good reasons without that, 
as well.


--jcc


--
Connexions
http://cnx.org

Building Websites with Plone
http://plonebook.packtpub.com

___
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()

2007-08-26 Thread Eric
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()

2007-08-26 Thread Andreas Jung



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


[Zope] Re: Help with DateTime.earliestTime()

2007-08-25 Thread 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
  
[EMAIL PROTECTED] writes:
Sorry for the oversight...This occurs with zope-2.9.5 and zope-2.9.7
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 )