[Zope3-dev] mini-RFC: times and timezones

Gary Poster gary at zope.com
Thu Feb 24 11:50:04 EST 2005


On Feb 24, 2005, at 11:17 AM, Garrett Smith wrote:

> Gary Poster wrote:
>> On Feb 24, 2005, at 9:45 AM, Garrett Smith wrote:
>>> A datetime without a tz is either UTC or "dont care", which is known
>>> to the application. I've found this to work pretty well.
>>
>> Except this is not explicit--with that approach, a datetime without a
>> tz may be either, as you said.  You have to know what generated the
>> datetime in order to know the meaning.  I think we've experience pain
>> with this sort of guessing/implicit knowledge pattern in the past.
>
> This is the key. I'm not aware of the specific problems you've faced in
> the past.
>
> The only dates I'm aware of in Zope are uses of now() generated for
> events. I can't think of a reason not to always use utcnow(), which
> means that all dates in Zope are UTC.

Unless they are not--from an add-in product, from other Python 
libraries, etc.  Adding a timezone specifies the contract.

> What are some cases in which we need to store tz info?

Whenever you don't know the context from which a date comes, or don't 
want to have to guess.  By putting the contract on the datetime rather 
than on the source of the datetime you simplify code because datetime 
code does not have to figure out the datetime's source.  Zope 3 is 
about component architecture: specifying contracts explicitly so that 
guessing is ideally a thing of the past.  Any code that wants to deal 
with datetimes generically will want the contract on the object.

The explicitness pattern is common to Python and Zope best practices.  
I'm suggesting that this is an application of the best practices for 
datetimes.

Tim gave an example in which time-zone aware dates makes localizing 
them easier.  Tim also mentioned that Guido saw time-zone aware and 
time-zone naive dates as two very different beasts that don't play well 
together.  Zope 3 is an internationalized application, and 
timezone-aware datetimes are the appropriate standard on which to 
settle for our sort of app.

I'm not sure how to explain my position better (and I'm complaining 
about my communication skills, not your reading skills) :-(.  How 
strongly do you oppose this?

Gary



More information about the Zope3-dev mailing list