Stuart Bishop wrote:
Ignas Mikalajunas wrote:
Thanks. I'd seen localize() in the README but all the examples have an
explicit is_dst passed which I didn't want. I didn't realize that
without it it would guess the right one (except during the 1h ambiguous

The is_dst parameter is more like "If it is ambiguous prefer DST",
even when calling localize without passing the parameter it will not
do any guessing as is_dst is set to False by default. If you want
localize to warn you about ambiguous time you should pass is_dst=None
which will raise an exception instead of assuming that you prefer non
DST times in ambiguous cases,

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).

If my French user say "this expires 15 aug 2006 at 16:00" I want them to see "15/08/2006 16:00" in the document metadata, even though it's stored as 2006-08-15T16:00:00+0200. If the document is exported to another system, I want the timezone kept.


Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   [EMAIL PROTECTED]
Zope3-dev mailing list

Reply via email to