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

[Garrett Smith]

Gary Poster wrote:
> Problems:
> - working with mixed Python timezone-aware and -naive datetimes is a
> big pain (i.e., they don't work together well, and are not intended to
> AFAIK).

:) Has anyone *not* Googled:

  TypeError: can't compare offset-naive and offset-aware datetimes

> - Given a choice, timezone-aware datetimes are more explicit, clear,
> and effective.  The Zope 3 code base does not use timezone-aware
> datetimes. [1]

I've gone the other way -- I store everything without a time zone. 

I've found that maintaining time zone info is a pain:

- A great source of annoying bugs
- RDBs often don't support tz

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.

> - Displaying datetimes in UTC is not user friendly.  Users should see
> datetimes in their timezones.

Yep

> Other observations:
> - Working internally with utc datetimes is considered best
>   practice[4]. The Zope 3 code base does store UTC dates, just
> without a timezone. 

I prefer this.

> Suggested Solution:
> - zope.i18n should grow a picklable utc timezone that behaves well
> with datetime.now()[5]
> - datetimes generated in the Zope core to be stored should have a utc
> timezone (i.e., datetime.now(zope.i18n.utc)--again, see footnote [5])

I don't see the advantage here.

Where do we deal with time zone's, from an input standpoint, that forces
us to work with tz-aware values?

(I agree that display should *usually* take tz into account, but this is
up to the view.)

> - datetimes generated in the Zope core for display should always have
> "localized" timezones.  Specifically:
>    * zope.interface.common should grow an ITZInfo interface
>    * zope.app.i18n should grow an adapter that adapts a default
> request to an ITZInfo.  It will be intentionally dumb--always
> returning i18n.utc--but will be intended to be a hook point for
> applications to specify other defaults or heuristics for getting the
> appropriate display timezone for a given request.  If anyone wants to
> improve the default, great, but I'm not planning on it.

Don't we grab tz info from the browser request in parseDatetimetz? I
would imagine this would be the default adapter for browser requests.

>    * zope.i18n should grow a convenience method to convert dates from
> utc to another timezone [6]

It's surprising that Python's datetime module doesn't do this.

But, if datetime values are stored sans-tz, we probably need this a lot
less. (Not addressing locale-specific formatting here.)

>    * Views should generally display dates (stored with a UTC timezone)
> using something like this:
>          formatter = request.locale.dates.getFormatter('dateTime',
> length='short')
>          tz = zope.interface.common.tzinfo.ITZInfo(request)
>          return formatter.format(zope.i18n.switchTimeZones(date, tz)

I haven't looked at that code in a while, but I would hope that:

  request.locale.dates.getFormatter(...)

would provide a formatter that displayed localized time given a UTC
value (no time zone). If it doesn't, it seems like a bug.

So, if we don't lug around tz, the 'switch' requirement goes away:

  formatter = request.locale.dates.getFormatter(...)
  return formatter.format(date)

(If the value has a tz, the formatter should not convert the value to
the locale time zone.)

> Objections?  I'd like schoolbell(/tool) folks to buy in on this as
> well, ideally.  This should be pretty easy for me to throw together if
> everyone is ok with it.

The change seems like some unneeded complexity, but I'm not not making a
formal objection :)

Let me just summarize:

- Storing time zones is pain -- avoid it unless the application calls
for it. The fact that all Zope dates will have the same offset (0) tells
me this isn't needed.

- Only worry about 'switching' during formatting. And it's not so much
'switching' as 'display this in my time zone'.

My 2 cents anyway :)

 -- Garrett