[Zope] Re: datetime bug

[Dennis Allison]

Thanks Lupa.

I have tracked it down and created a patch which fixes the problem in 
general.   Seems the ISO 8601 implementation had some warts.  We are 
testing the patch now.  When I am sure it's OK I'll submit it to the
Collector with an "URGENT" tag.  I'll also send you a copy.  

I suspect that the daylight savings time behavior is unrelated to this 
problem and is likely to be a bad entry in a table.  

Thanks for you helpful response.  BTW if you want an alpha copy of the 
patch, let me know and I'll send it to you.  The more testing the better.


The patched version has the following semantics

	dates and times with no timezone tag resolve to the 
	timezone of the host machine (Zope standard behavior)

	dates and times with a trailing Z are guaranteed to be 
	GMT

	dates and times with a trailing offset have the offset
	as their time zone.

	It is illegal to combine a 'Z' and an offset.  (Hacked in 
	the code for 2.7 beta)

I think this matches the spec at 

	http://www.w3.org/TR/NOTE-datetime

On Sun, 12 Jun 2005, +lupa+ wrote:

> Hi Dennis,
>     I'm responding directly to you as I'm not on the zope list.  I see the 
> same error on Zope 2.7.6 and with 2.3.5 python, not 2.4.x.  I've narrowed 
> the behavior down a bit more and it seems that
> 
> >              dd = '%d-%02d-%02d' % (y,m,d,)
> >              D  = DateTime(dd)
> 
> converts to local time, while
> 
> >              ee  = '%d/%d/%d' % (m, d, y)
> >              E  = DateTime(ee)
> 
> converts to Mean time.  I'm not absolutely sure of that, but in a quick 
> look, I can see that the difference between D and E changes from -5 hours 
> to -3 when Daylight Savings Time change comes around... which seems a bit 
> weird in itself.   I wrote and maintain CalendarX for Plone, so this 
> behavior concerns me greatly and I'll be looking into it more very soon.
> 
> +lupa+
> Lupa Zurven, CalendarX.org
> 
> 
> 
> 
> 
> 
> 
> At 12:00 PM 6/12/2005 -0400, you wrote:
> >From: Dennis Allison <allison at shasta.stanford.edu>
> >Precedence: list
> >Subject: [Zope] Datetime bug in Zope-2.7.6?
> >Date: Sat, 11 Jun 2005 16:54:03 -0700 (PDT)
> >To: zope at zope.org
> >Message-ID: <Pine.LNX.4.44.0506111632260.3493-100000 at shasta.stanford.edu>
> >Content-Type: TEXT/PLAIN; charset=US-ASCII
> >MIME-Version: 1.0
> >Message: 5
> >
> >
> >Zope 2.7.6
> >Python 2.4.1 (and yes, I know I am jumping the gun a bit)
> >
> >The problem appears to be in the parse component --
> >
> >Consider a test script:
> >
> >for y in range(1995,2005):
> >     for d in (1, 3, 13, 25,):
> >         for m in (1,4,5,6,):
> >              dd = '%d-%02d-%02d' % (y,m,d,)
> >              ee  = '%d/%d/%d' % (m, d, y)
> >              D  = DateTime(dd)
> >              E  = DateTime(ee)
> >              print dd, D.strftime('%Y-%m-%d')
> >              print ee, E.strftime('%Y-%m-%d')
> >return printed
> >
> >In all cases, each of the dates shoudl be the same.  As can be seen,
> >for dates sourced from a string of the form
> >
> >1995-04-25
> >
> >the resulatant date is off by one day
> >
> >1995-04-24
> >
> >The problem is not seen with Zope 2.6.4 running with
> >Python 2.3.5.
> >
> >A quick diff shows tht there are many changes between 2.6 and 2.7.
> >Anyone else seen this problem?
> >
> >------------------------------------
> >Partial Results:
> >
> >1995-04-25 1995-04-24
> >4/25/1995 1995-04-25
> >
> >1995-05-25 1995-05-24
> >5/25/1995 1995-05-25
> >
> >1995-06-25 1995-06-24
> >6/25/1995 1995-06-25
> >
> >--
> >Dennis Allison * Computer Systems Laboratory * Gates 227
> >                * Stanford University *  Stanford CA  94305
> >                * (650) 723-9213 * (650) 723-0033 fax
> >                * allison at shasta.stanford.edu
> >                * allison at sumeru.stanford.edu
> 

-- 
Dennis Allison * Computer Systems Laboratory * Gates 227
               * Stanford University *  Stanford CA  94305
	       * (650) 723-9213 * (650) 723-0033 fax
	       * allison at shasta.stanford.edu
	       * allison at sumeru.stanford.edu