> The same problem happens when:
> 1) Using _.DateTime(datestring)
> 2) The datestring has minus-sign as year, month, date separators.
> 3) A format is applied, like fmt="%d DE %B %Y"
> The following are examples when viewing a DTML Document containing :
> <dtml-var "_.DateTime('2005-05-25')"><br>
> <dtml-var "_.DateTime('2005/05/25')" fmt="%d DE %B %Y" upper><br>
> <dtml-var "_.DateTime('2005-05-25')"><br>
> <dtml-var "_.DateTime('2005-05-25')" fmt="%d DE %B %Y" upper><br>
> Output is:
> 2005/05/25
> 25 DE MAYO 2005
> 2005/05/25
> 24 DE MAYO 2005
> Look at the last one 24 DE MAYO 2005, that is wrong !
> In the last case, Zope assumes the date to be at midnight GMT and then,
> when I apply the formatting (fmt="%d DE %B %Y") it substracts 5 hours
> from GMT to get to my local timezone, resulting the date is 1 day off
> the real date.

The hyphen-delimited Y-m-d format is an ISO standard, ISO 8601, and is
therefore always in UTC. You'll need to specify it as 2005-05-25T00-05
for 5 hours before.

> I think Zope should not assume that a date is in any particular time
> zone, nor in midnight GMT when using minus-signs as separators, rather
> it should take the system's time zone settings into account when
> applying datetime formatting. Therefore, if there's the need to use
> dashes, there should be no reason to explicit state a time zone when the
> user is only entering a simple date (year, month, day).
> In other words, why using dashes is acting like a bug, instead of
> working like the first casem using "/" as separator ?

Because it's not a bug, you're specifying an ISO 8601 date with no
timezone qualifier, so it's assuming UTC, just like the spec says. I'm
not claiming that the behaviour is what people want, but as long as
Zope interprets ISO 8601 by the standard, then this isn't really a

Phillip Hutchings
Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to