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

[Garrett Smith]

Gary Poster wrote:
> 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.

There's also the KISS pattern, which is probably motivating my push
back.

And also the "ain't broke, don't fix" pattern.

"It's either UTC or I don't care" has served all the applications I've
seen. I'm not saying there isn't a good reason to be explicit (other
than to be explicit). I just don't have the experience. It's why I'm
asking :)

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

My only bottom line is that if working with datetime values in Zope is
going to get trickier (more stuff to deal with, more lines of code,
etc.) I'd like to see the payoff. The explicitness argument is too
esotheric if code/system get more complicated.

There must be something driving specific this change that's prompting
the urgency, so certainly don't hold up on my account. I'm sure we can
smooth out any rough edges, if there are any. 

 -- Garrett