[Zope3-dev] Re: [Python-Dev] Holes in time

[Tim Peters]

[Leonardo Rochael Almeida, on DST in Brazil]
> Actually, it's worse than that. It's a different day every single year!
> And it's decide by a decree! (or law or some other political decision
> thingie which I don't remember) It's usually decided to match a
> saturday-sunday transition so as to make it easier on people biological
> clocks.
>
> And if you think that's bad enough, this last year the Governor of the
> state of Goi=E1s decided for some unknown reason that his state would n=
ot
> to enter into DST with the rest of DST states (states to the north of
> Brazil don't enter DST, as they're too close to the Equator to actually
> gain anything from DST), and so he passed a state law to that effect.
> The federal government sued and asked for an injuction, at which point =
I
> stopped following the confusion :-)

The datetime tzinfo gimmicks are strong enough to model all that, via cod=
ing
per-year rules into a tzinfo subclass's dst() method.  I doubt anyone wil=
l
be interested enough to bother, though <wink>.

> ...
> Anyway, to bing this e-mail back on topic, I like the unix solution to
> the problem: all times are in UTC and a conversion is made when a user
> needs the local time, since "utc -> local time" is a function.

If you want to view naive datetimes as being in UTC, and force yourself t=
o
convert them to local times as/when needed, that's supported.  It's not
expected, though:  the design expects that most people are interested in
their own local time, and that mostly they just want to print it in vario=
us
ways.  In that case, you can view naive datetimes as being in your local
time just as well.  For example, a recurring weekly meeting at 2pm Thursd=
ay
is almost certainly at "2pm local time" regardless of DST shifts, and so =
is
more regular in local time than in UTC.  If you want to account for that
it's not always at the same hour in UTC, that's fine too, but may be
extravagant (depending on other needs the app may have).

> If storing local times is necessary, it should have a "isDST" field or
some
> such.

You can set the tzinfo member of a datetime object to whatever you like. =
 I
can't say whether that's sufficient without a concrete use case.  Note th=
at
the members of a datetime object are always viewed as being "in local tim=
e",
where "local" is relative to the rules coded by the tzinfo member.