Mailing List Archive

1 2  View All
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically. [ In reply to ]
On 31/08/2021 22:32, Chris Angelico wrote:

> If we could abolish DST world-wide, life would be far easier. All the
> rest of it would be easy enough to handle.
We tried that in the UK for 2 years back in the '70s and very
quickly reverted to DST when they realized that the number
of fatalities among young children going to school doubled
during those two years.

Without DST the schools opened in the dark so all the kids
had to travel to school in the dark and the number of
traffic accidents while crossing roads jumped.

In fact during WW2 they increased DST to 2 hours (that
was for the farmers!) because it meant that farm labourers
would start work at first light, effectively extending
the working day.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically. [ In reply to ]
On 31/08/2021 23:31, Chris Angelico wrote:

> Ah, good to know. I think that actually makes a lot of sense; in the
> US, they try to let everyone pretend that the rest of the world
> doesn't exist ("we always change at 2AM"), but in Europe, they try to
> synchronize for the convenience of commerce ("everyone changes at 1AM
> UTC").

There's another gotcha with DST changes. The EU and USA have different
dates on which they change to DST.

In one of them (I can't recall which is which) they change on the 4th
weekend of October/March in the other they change on the last weekend.

That means on some years (when there are 5 weekends) there is a
week when one has changed and the other hasn't. That caused us
a lot of head scratching the first time we encountered it because
our service centres in the US and EU were getting inconsistent
time reporting and some updates showing as having happened in
the future!

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically. [ In reply to ]
On Fri, Sep 3, 2021 at 4:18 AM Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
>
> On Tue, 31 Aug 2021 16:53:14 -0500, 2QdxY4RzWzUUiLuE@potatochowder.com
> declaimed the following:
>
> >On 2021-09-01 at 07:32:43 +1000,
> >Chris Angelico <rosuav@gmail.com> wrote:
> >> If we could abolish DST world-wide, life would be far easier. All the
> >> rest of it would be easy enough to handle.
> >
> >Agreed.
> >
>
> Unfortunately, most of the proposals in the US seem to be that
> /standard time/ would be abolished, and DST would rule year-round. Hence
> putting the center of the time zone one hour off from solar mean noon;
> which is what the time zones were originally based upon.
>

I'd be fine with that, honestly. It's a bit 'off', but it isn't THAT
big a deal. If some city in the US decides that it wants its timezone
to be a few hours AHEAD of UTC, more power to them, just as long as
it's consistent year-round.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically. [ In reply to ]
On Fri, Sep 3, 2021 at 4:22 AM Alan Gauld via Python-list
<python-list@python.org> wrote:
>
> On 31/08/2021 22:13, Chris Angelico wrote:
>
> > But ultimately, it all just means that timezones are too hard for
> > humans to handle, and we MUST handle them using IANA's database. It is
> > the only way.
>
> 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? IANA maintains the database by noticing changes
and announcements, and updating the database. I don't think
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.

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.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically. [ In reply to ]
On Fri, Sep 3, 2021 at 4:26 AM Alan Gauld via Python-list
<python-list@python.org> wrote:
>
> On 31/08/2021 22:32, Chris Angelico wrote:
>
> > If we could abolish DST world-wide, life would be far easier. All the
> > rest of it would be easy enough to handle.
> We tried that in the UK for 2 years back in the '70s and very
> quickly reverted to DST when they realized that the number
> of fatalities among young children going to school doubled
> during those two years.
>
> Without DST the schools opened in the dark so all the kids
> had to travel to school in the dark and the number of
> traffic accidents while crossing roads jumped.

How do they manage in winter? Can that be solved with better street
lighting? That was fifty years ago now, and the negative consequences
of DST are far stronger now.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically. [ In reply to ]
On Fri, Sep 3, 2021 at 4:40 AM Alan Gauld via Python-list
<python-list@python.org> wrote:
>
> On 31/08/2021 23:31, Chris Angelico wrote:
>
> > Ah, good to know. I think that actually makes a lot of sense; in the
> > US, they try to let everyone pretend that the rest of the world
> > doesn't exist ("we always change at 2AM"), but in Europe, they try to
> > synchronize for the convenience of commerce ("everyone changes at 1AM
> > UTC").
>
> There's another gotcha with DST changes. The EU and USA have different
> dates on which they change to DST.
>
> In one of them (I can't recall which is which) they change on the 4th
> weekend of October/March in the other they change on the last weekend.
>
> That means on some years (when there are 5 weekends) there is a
> week when one has changed and the other hasn't. That caused us
> a lot of head scratching the first time we encountered it because
> our service centres in the US and EU were getting inconsistent
> time reporting and some updates showing as having happened in
> the future!
>

I live in Australia. You folks all change in *the wrong direction*.
Twice a year, there's a roughly two-month period that I call "DST
season", when different countries (or groups of countries) switch DST.
It is a nightmare to schedule anything during that time.

The ONLY way is to let the computer handle it. Don't try to predict
ANYTHING about DST manually.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically. [ In reply to ]
On 2021-09-02 08:40, Alan Gauld via Python-list wrote:
> On 31/08/2021 23:31, Chris Angelico wrote:
>
>> Ah, good to know. I think that actually makes a lot of sense; in the
>> US, they try to let everyone pretend that the rest of the world
>> doesn't exist ("we always change at 2AM"), but in Europe, they try to
>> synchronize for the convenience of commerce ("everyone changes at 1AM
>> UTC").
>
> There's another gotcha with DST changes. The EU and USA have different
> dates on which they change to DST.
>
> In one of them (I can't recall which is which) they change on the 4th
> weekend of October/March in the other they change on the last weekend.
>
> That means on some years (when there are 5 weekends) there is a
> week when one has changed and the other hasn't. That caused us
> a lot of head scratching the first time we encountered it because
> our service centres in the US and EU were getting inconsistent
> time reporting and some updates showing as having happened in
> the future!
>
In the EU (and UK) it's the last Sunday in March/October.

In the US it's second Sunday in March and the first Sunday in November.

I know which one I find easier to remember!
--
https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically. [ In reply to ]
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?

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

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

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically. [ In reply to ]
On 02/09/2021 20:11, MRAB wrote:

>> In one of them (I can't recall which is which) they change on the 4th
>> weekend of October/March in the other they change on the last weekend.
>>
>>
> In the EU (and UK) it's the last Sunday in March/October.
>
> In the US it's second Sunday in March and the first Sunday in November.
>
> I know which one I find easier to remember!

Interesting. I remember it as closer than that. The bugs we found were
due to differences in the DST settings of the BIOS in the PCs. (They
were deliberately all sourced from DELL but the EU PCs had a slightly
different BIOS).

The differences you cite should have thrown up issues every year.
I must see if I can find my old log books...

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically. [ In reply to ]
On Fri, Sep 3, 2021 at 8:01 AM Alan Gauld via Python-list
<python-list@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
--
https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically. [ In reply to ]
On 02/09/2021 19:30, Chris Angelico wrote:

>> Without DST the schools opened in the dark so all the kids
>> had to travel to school in the dark and the number of
>> traffic accidents while crossing roads jumped.
>
> How do they manage in winter?

That was the winter. Sunrise wasn't till 10:00 or so
and the schools open at 9. With DST sunrise became
9:00 and with pre-dawn light it is enough to see by.

Its a recurring theme. Every now and then some smart
young politician from the south of the UK suggests
doing away with DST and a large crowd of northerners
jump up and say no way!

> Can that be solved with better street> lighting?

They had street lighting but it casts dark shadows etc.
In fact modern LED based street lighting is worse in
that respect that the old yellow sodium lights were.
But where it doesn't exist the cost of installing
street lighting in small villages is too high compared
to just changing the clocks. And of course street
lighting has a real running cost that would be reflected
in the local council taxes, and nobody wants to
pay more of them! After all street lighting has
been available for over 150 years, if they haven't
installed it by now.... (I mean, nearly everywhere
has some lighting, at least on the main roads,
it's just the smaller back streets that tend to be dark.)

> That was fifty years ago now, and the negative consequences
> of DST are far stronger now.

But not apparent to most people. Most still see it
as a benefit because they get longer working daylight.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically. [ In reply to ]
On Sat, Sep 4, 2021 at 3:33 AM Alan Gauld via Python-list
<python-list@python.org> wrote:
>
> On 02/09/2021 19:30, Chris Angelico wrote:
>
> >> Without DST the schools opened in the dark so all the kids
> >> had to travel to school in the dark and the number of
> >> traffic accidents while crossing roads jumped.
> >
> > How do they manage in winter?
>
> That was the winter. Sunrise wasn't till 10:00 or so
> and the schools open at 9. With DST sunrise became
> 9:00 and with pre-dawn light it is enough to see by.

Are you saying that you had DST in winter, or that, when summer *and*
DST came into effect, there was more light at dawn? Because a *lot* of
people confuse summer and DST, and credit DST with the natural effects
of the season change.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically. [ In reply to ]
On 03/09/2021 18:37, Chris Angelico wrote:

>>>> Without DST the schools opened in the dark so all the kids
>>>> had to travel to school in the dark and the number of
>>>> traffic accidents while crossing roads jumped.
>
> Are you saying that you had DST in winter, or that, when summer *and*
> DST came into effect, there was more light at dawn? Because a *lot* of
> people confuse summer and DST, and credit DST with the natural effects
> of the season change.

OK, I see the confusion. What I should point out was that the
experiment involved us staying on DST and not reverting to UTC
in the winter - that unified us with most of the EU apparently...

So although I'm saying DST it was really the non-reversion from
DST to UTC that caused problems. Arguably, if we just stayed on
UTC and didn't have DST at all there would be no issue - except
we'd be an hour out of sync with the EU. (Post Brexit that may
not be seen as a problem!! :-)

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically. [ In reply to ]
On 2021-09-02 08:32:36 +0100, Alan Gauld via Python-list wrote:
> On 31/08/2021 22:32, Chris Angelico wrote:
> > If we could abolish DST world-wide, life would be far easier. All the
> > rest of it would be easy enough to handle.
> We tried that in the UK for 2 years back in the '70s and very
> quickly reverted to DST when they realized that the number
> of fatalities among young children going to school doubled
> during those two years.

That makes no sense. With DST the clocks are changed in summer, and they
are set forward, so it's darker at the same time in the morning.

Maybe you are talking about switching to DST for the whole year or just
moving to CET? That would have the effect of it being noticably darker
in the morning in winter.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically. [ In reply to ]
On 2021-09-04 21:48:14 +0200, Peter J. Holzer wrote:
> On 2021-09-02 08:32:36 +0100, Alan Gauld via Python-list wrote:
> > On 31/08/2021 22:32, Chris Angelico wrote:
> > > If we could abolish DST world-wide, life would be far easier. All the
> > > rest of it would be easy enough to handle.
> > We tried that in the UK for 2 years back in the '70s and very
> > quickly reverted to DST when they realized that the number
> > of fatalities among young children going to school doubled
> > during those two years.
>
> That makes no sense. With DST the clocks are changed in summer, and they
> are set forward, so it's darker at the same time in the morning.
>
> Maybe you are talking about switching to DST for the whole year or just
> moving to CET? That would have the effect of it being noticably darker
> in the morning in winter.

Found it. Between 1968-02-18 and 1971-10-30 was continuously on
UTC+0100 (probably to be in the same timezone as Germany and France
(which didn't have DST at that time).

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically. [ In reply to ]
On Sun, Sep 5, 2021 at 12:39 PM Alan Gauld via Python-list
<python-list@python.org> wrote:
>
> On 03/09/2021 18:37, Chris Angelico wrote:
>
> >>>> Without DST the schools opened in the dark so all the kids
> >>>> had to travel to school in the dark and the number of
> >>>> traffic accidents while crossing roads jumped.
> >
> > Are you saying that you had DST in winter, or that, when summer *and*
> > DST came into effect, there was more light at dawn? Because a *lot* of
> > people confuse summer and DST, and credit DST with the natural effects
> > of the season change.
>
> OK, I see the confusion. What I should point out was that the
> experiment involved us staying on DST and not reverting to UTC
> in the winter - that unified us with most of the EU apparently...
>
> So although I'm saying DST it was really the non-reversion from
> DST to UTC that caused problems. Arguably, if we just stayed on
> UTC and didn't have DST at all there would be no issue - except
> we'd be an hour out of sync with the EU. (Post Brexit that may
> not be seen as a problem!! :-)

Oh, I see what you mean.

When I complain about DST, I'm complaining about the repeated changes
of UTC offset. Whether you either stay on UTC+0 or stay on UTC+1, it's
basically the same, doesn't make a lot of difference. "Abolishing DST"
and "staying on summer time permanently" are effectively the same.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

1 2  View All