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

[Chris Angelico]

On Tue, Aug 31, 2021 at 8:55 PM MRAB <python at mrabarnett.plus.com> wrote:
>
> On 2021-08-31 02:16, dn via Python-list wrote:
> > On 31/08/2021 11.07, Dennis Lee Bieber wrote:
> >> On Sun, 29 Aug 2021 19:49:19 -0700 (PDT), "hongy... at gmail.com"
> >> <hongyi.zhao at gmail.com> declaimed the following:
> > ...
> >
> >>      Might have helped to mention you were in China... To me, CST is North
> >> America Central Standard Time (and I'd have expected this time of year to
> >> see CDT - Central Daylight Time)... That led me on a weird meaningless side
> >> track...
> > ...
> >
> >>      I'm in EDT (Eastern Daylight Time) -- so 4 hours behind UTC.
> >
> >
> > Which is correct?
> >
> > CST in China
> > https://www.timeanddate.com/time/zones/cst-china
> >
> > CST in North America
> > https://www.timeanddate.com/time/zones/cst
> >
> > and not to mention Cuba
> > https://www.timeanddate.com/time/zones/
> >
> [snip]
> What annoys me is when someone starts that a webinar will start at, say,
> xx ET. I have to know which country that person is in and whether
> daylight savings is currently in effect (EST or EDT?) so that I can
> convert to my local time.

If someone says "ET", then I would assume they mean America/New_York -
it seems that only in the US do people so utterly assume that everyone
else is in the same country. In Europe, I hear people say "CEST" and
such (though I still prefer "Europe/Prague" or whatever country
they're in), so the only issue there is that they don't always say
"CEDT" when it's daylight time.

> It's so much easier to use UTC.
>
> I know what timezone I'm in and whether daylight savings is currently in
> effect here, so I know the local offset from UTC.

Yeah. I do recommend making good use of the IANA tzinfo database
though (especially since Python 3.9 made that a bit easier to access),
as it's usually easier to get people to tell you what city/state
they're in, rather than whether daylight time will be active or not.
(It might take a little bit of translation to figure out that, for
instance, New Brunswick CA is America/Halifax, but that's not too hard
usually.) Letting tzinfo do all the work means you don't have to fret
about anyone's daylight saving transition dates, or whether they've
decided to change their clocks by half an hour to be different from
Japan's clocks, or to have DST not applicable during Ramadan, or to
have double DST, or double-negative DST. And yes, those are all real,
because you can't make up anything as insane as actual clock politics.

(I find the Ireland situation particularly amusing. Northern Ireland,
being part of the UK, operates on London time, with clocks advancing
one hour for summer. The Republic of Ireland, on the other hand, has a
standard time which is one hour later than Greenwich's, but then they
subtract an hour during winter, returning to standard time in summer.
So when the rest of Europe adds an hour, Ireland stops subtracting
one. Clocks in Belfast and Dublin always show the same times.)

ChrisA