The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Chris Angelico]

On Fri, Sep 3, 2021 at 8:01 AM Alan Gauld via Python-list
<python-list at python.org> wrote:
>
> On 02/09/2021 19:28, Chris Angelico wrote:
>
> >> Except for the places that don't follow the IANA scheme and/or
> >> dynamically change their time settings on a whim. To be complete
> >> you need the ability to manually override too.
> >>
> >
> > What places are those?
>
> Mainly small non-tech oriented places such as small pacific islands
> or principalities with local governance - such as by a group of
> tribal elders. I mentioned earlier the example of Andorra announcing
> on the Friday night before a DST change that they were deferring
> it for a week to preserve the skiing conditions. But we came across
> several similar situations in dealing with multi-national service centres.
>
> > IANA maintains the database by noticing changes
> > and announcements, and updating the database.
>
> But don;t those have to be electronic in nature? How, for example
> would it pick up the radio news announcement mentioned above?

Can't find the specific example of Andorra, but there have been plenty
of times when someone's reported a time change to the IANA list and
it's resulted in the zonedata being updated. "It" picks up changes by
people reporting them, because IANA is, ultimately, a group of people.

> > governments need to "opt in" or anything. Stuff happens because people
> > do stuff, and people do stuff because they want to be able to depend
> > on timezone conversions.
>
> Umm, they do DST because it makes their lives easier - more daylight,
> extra work time. etc. The needs of, or impact on, computers in these
> kinds of small localities and communities are way down the pecking order.

Yes, and what happens when those changes make other people's lives
harder because tzdata is out of date? People change tzdata to be
up-to-date. It's not the local government that maintains tzdata.

> > There ARE times when a government makes a change too quickly to get
> > updates out to everyone, especially those who depend on an OS-provided
> > copy of tzdata, so I agree with the "on a whim" part. Though,
> > fortunately, that's rare.
>
> I agree it is very rare and if you only operate in mainstream
> localities you probably never see it as an issue, it's only
> when you need to support "off grid" locations that manual
> control becomes important. Also the problems we had were about
> 15 years ago, things may be better ordered nowadays. (I've been
> retired for 7 years so can't speak of more recent events)

Oh, fifteen years ago. That explains why searching the tz-announce
list didn't help - the archive doesn't go back past 2012. The actual
tzdata files can be found going all the way back [1] but you'd have to
dig through to find the announcement in question. In any case, I'm
sure you'll find an update there; if not immediately, then after the
event, because tzdata cares a LOT about historical times. For
instance, this recent announcement [2] had one change to upcoming
times, but a number of corrections to past times.

So a manual override is ONLY necessary when (a) tzdata hasn't caught
up yet, or (b) tzdata has been updated, but you're using an old
version (maybe your OS hasn't caught up yet, and you can't get it from
PyPI).

ChrisA

[1] https://data.iana.org/time-zones/releases/
[2] https://mm.icann.org/pipermail/tz-announce/2020-December/000063.html