Florent Guillaume wrote at 2006-8-7 12:53 +0200:
>On 5 Aug 2006, at 22:38, Dieter Maurer wrote:
>> Florent Guillaume wrote at 2006-8-5 00:17 +0200:
>>> Stuart Bishop wrote:
>>> ...
>>>> I've been wondering if making pytz work like this was a correct  
>>>> decision. It
>>>> seems that people who know enough to care about DST transition  
>>>> periods
>>>> generally work in UTC anyway
>>> What makes you say that? Any application where datetimes are
>>> user-entered and user-visible will certainly *not* want to store  
>>> them in
>>> UTC, as users will want dates displayed "as they were  
>>> entered" (meaning
>>> holding their original timezone, even if the timezone is not  
>>> displayed).
>> *nix recommends to store the time in UTC (in the hardware clock).
>> Nevertheless, users see and can enter the time in their local  
>> timezone.
>Unix has nothing to do with an application manipulating proper  
>calendaring concepts. The original timezone information can be quite  
>important, and the local timezone of the user seeing the information  
>may not be the appropriate one.
>> This demonstrates that the storage format can be independent of what
>> the user sees or enters...
>Provided all you want is store an instant in time. Which is only a  
>limited subset of what can be useful in general.

A look at "iCal" (RFC 2445) shows that you can either use UTC
(maybe with a tacit knowledge about the timezone of the location
the calendar event applied to in order to get its local time) or explicitely 
use the "TZID" parameter (such that an interesting interpreter can
convert to UTC).

Only when you give the timezone an implicit (!) meaning (e.g. it's the timezone
applying to the location of the event) you get more than with UTC alone.

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to