Happy New Year!!!

It seems only right that readers of <a.f.c.> should post (or re-post)
computer screw-ups that involve the change to a new year, or in some way
are related to leap year or century or millennium changes or etc. etc.

Vaguely I seem to recall something about a Microsoft music player
hanging up (stopped working) after 1000 days because of a counter
wrapping around to zeroes.

Maybe we can also include stories involving a failure to "feed the
watchdog timer" quickly enough.

Two digit to four digit date conversion stories should be included...
don't you think???

--

Charles Richmond

--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Am 31.12.2022 um 22:35:16 Uhr schrieb Charles Richmond:

> It seems only right that readers of <a.f.c.> should post (or re-post)
> computer screw-ups that involve the change to a new year, or in some
> way are related to leap year or century or millennium changes or etc.
> etc.

I haven't experienced the millenium change, I was born in 2001,
although I have a fax machine/printer/copier that can only use 2-digit
year, but it doesn't create problems if It set it to 22. I haven't used
it in 2023, so I don't know if it still works with the year 23. :-)

> Vaguely I seem to recall something about a Microsoft music player
> hanging up (stopped working) after 1000 days because of a counter
> wrapping around to zeroes.

Was that the "Media Player" (not WMP) or the later WMP?
I have read a similar story about Win 9x with about 40 days.

I have a network card (Broadcom PCI) that stopped working after a
certain amount of time or transferred data. If anybody is interested, I
can find out more.

The software "bmon" crashes after a certain amount of transmitted data
with a segfault. I assume a counter overflow, but I need to examine
that.

On Sat, 31 Dec 2022 22:35:16 -0600
Charles Richmond <codescott@aquaporin4.com> wrote:

> Happy New Year!!!
>
> It seems only right that readers of <a.f.c.> should post (or re-post)
> computer screw-ups that involve the change to a new year, or in some way
> are related to leap year or century or millennium changes or etc. etc.
>

Seems it was 23 years ago. Gosh.

> Vaguely I seem to recall something about a Microsoft music player
> hanging up (stopped working) after 1000 days because of a counter
> wrapping around to zeroes.
>
> Maybe we can also include stories involving a failure to "feed the
> watchdog timer" quickly enough.
>
> Two digit to four digit date conversion stories should be included...
> don't you think???
>

--
Bah, and indeed Humbug.

Hello everyone!

01 Jan 23 10:46, you wrote:

MM> I have read a similar story about Win 9x with about 40 days.

I used an old PC to act as a WiFi client and router in my parents house
around 2004 and as it was an old Pentium-class machine and Linux didn't
support my PCI WiFi card at first, I had Windows 98 running there. I can
confirm, that the memory management bug, that makes the system go out of
free RAM after about 40 days, was there. I was living about 200 km away
from my parents back then as I was on the university, and my mum had to go
every month to the attic and reset the machine.

I was really glad when ndiswrapper started to work with that PCI card and I
could migrate the machine to Linux :)

Martin

.... All bugs encountered until reboot are features.

On Sat, 31 Dec 2022 22:35:16 -0600, Charles Richmond wrote:
>
> Happy New Year!!!

Same to all of you and the user still using the usenet!

> It seems only right that readers of <a.f.c.> should post (or re-post)
> computer screw-ups that involve the change to a new year, or in some
> way are related to leap year or century or millennium changes or
> etc. etc.
>
> Vaguely I seem to recall something about a Microsoft music player
> hanging up (stopped working) after 1000 days because of a counter
> wrapping around to zeroes.

Not entirely to the subject. But a few years ago I played with an
emulator running OS/2. The image I ran also included StarOffice, so I ran
the setup. But it was a 90 days (or so) trial version. And after starting
it told me it would be after December 31 1996, so I couldn't try it
out. What a shame! ;-)
--
Andreas

On Sun Jan 1 11:41:54 2023 Martin Kukac wrote:
>
>
> Hello everyone!
>
> 01 Jan 23 10:46, you wrote:
>
> MM> I have read a similar story about Win 9x with about 40 days.
>
> I used an old PC to act as a WiFi client and router in my parents house
> around 2004 and as it was an old Pentium-class machine and Linux didn't
> support my PCI WiFi card at first, I had Windows 98 running there. I can
> confirm, that the memory management bug, that makes the system go out of
> free RAM after about 40 days, was there. I was living about 200 km away
> from my parents back then as I was on the university, and my mum had to go
> every month to the attic and reset the machine.
>
> I was really glad when ndiswrapper started to work with that PCI card and I
> could migrate the machine to Linux :)
>
> Martin
>
>
> ... All bugs encountered until reboot are features.

Hi everybody, happy new year
I'm new here
:-) Can't believe Usenet still exists in 2023

> It seems only right that readers of <a.f.c.> should post (or re-post)
> computer screw-ups that involve the change to a new year, or in some way
> are related to leap year or century or millennium changes or etc. etc.

I seem to recall a linux kernel bug involving a mis-handled leap second,
one NYE a decade+ back. Locked up the affected machines. One for which
I was responsible was ~80 miles away.

De

On Sun Jan 1 17:58:04 2023 drb@ihatespam.msu.edu (Dennis Boone) wrote:
> > It seems only right that readers of <a.f.c.> should post (or re-post)
> > computer screw-ups that involve the change to a new year, or in some way
> > are related to leap year or century or millennium changes or etc. etc.
>
> I seem to recall a linux kernel bug involving a mis-handled leap second,
> one NYE a decade+ back. Locked up the affected machines. One for which
> I was responsible was ~80 miles away.
>
> De

Talk about the devil. I recall once installing Gentoo, I finish compiling my manually compiled vmlinuz 9.6 MB, I had integrated everything into one big monolithical file (I wanted it to run as fast as possible) with NO initramfs.

Forgot to include the NVidia SATA device driver, spent the next 2 hours figuring out why the kernel panicked.

make menuconfig - fail!

Charles Richmond <codescott@aquaporin4.com> writes:

> Happy New Year!!!

> It seems only right that readers of <a.f.c.> should post (or re-post)
> computer screw-ups that involve the change to a new year, or in some way
> are related to leap year or century or millennium changes or etc. etc.

> Vaguely I seem to recall something about a Microsoft music player
> hanging up (stopped working) after 1000 days because of a counter
> wrapping around to zeroes.

> Maybe we can also include stories involving a failure to "feed the
> watchdog timer" quickly enough.

> Two digit to four digit date conversion stories should be included...
> don't you think???

We used to set the date on some of the systems at Living Computers: Museum+Labs
to 28 years earlier because there was no other way to get around the Y2K issue
on ancient operating systems. We had a note that after 31 December 2027 the
admins for those systems would need to subtract 56 from the date.

Sadly, we don't need to concern ourselves with that any longer.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On 2023-01-01, TheAppleFox <theapplefox@the.apple.fox> wrote:

> Hi everybody, happy new year
> I'm new here
>:-) Can't believe Usenet still exists in 2023

Happy New Year! Most of us are waiting to turn off the lights and lock
the door. There's very little Apple discussion in this group, but I've
found the group fascinating for years. Since I'm an Apple guy, I post
here rarely. :)
Put on your armor and have fun on Usenet! It's completely uncensored.

On 3 Jan 2023 01:22:54 GMT
Leonard Blaisdell <leoblaisdell@sbcglobal.net> wrote:

> On 2023-01-01, TheAppleFox <theapplefox@the.apple.fox> wrote:
>
> > Hi everybody, happy new year
> > I'm new here
> >:-) Can't believe Usenet still exists in 2023
>
> Happy New Year! Most of us are waiting to turn off the lights and lock
> the door. There's very little Apple discussion in this group, but I've
> found the group fascinating for years. Since I'm an Apple guy, I post
> here rarely. :)
> Put on your armor and have fun on Usenet! It's completely uncensored.

Apple? that's just for *users*!

HNY likewise.

--
Bah, and indeed Humbug.

On Sun, 2023-01-01, Charles Richmond wrote:
> Happy New Year!!!
>
> It seems only right that readers of <a.f.c.> should post (or re-post)
> computer screw-ups that involve the change to a new year, or in some way
> are related to leap year or century or millennium changes or etc. etc.
>
> Vaguely I seem to recall something about a Microsoft music player
> hanging up (stopped working) after 1000 days because of a counter
> wrapping around to zeroes.
>
> Maybe we can also include stories involving a failure to "feed the
> watchdog timer" quickly enough.
>
> Two digit to four digit date conversion stories should be included...
> don't you think???

I don't have one that I can recall. For most of my programming, time
has been either irrelevant or it has been the Unix time_t which
doesn't care. In 1999, my home computers ran Linux and people had
dealt with the Y2K bugs for me.

But recently I've had to use the Qt library's QDateTime[1] type, and
it occurred to me that this must be how people had to work before
someone (in the 1960s?) said "let's stop this nonsense and just count
seconds since some T=0".

A QDateTime is:
- a date
- a time-of-day
- a time zone

and it's easy to get wrong. Not so much at New Year, but when you
start messing with the time zone, you have to remember which function
preserves the time while shifting the time zone, and which function
instead preserves the date and time-of-day.

I suppose this type is a good fit when you need to format or parse a
time string, or need to do calculations on calendar time ("two days
ago") but the Qt framework encourages using it all the time[2], as a
replacement for time_t, struct timeval and friends.

/Jorgen

[1] https://doc.qt.io/qt-6/qdatetime.html
[2] Pun intended.

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Sun, 2023-01-01, Charles Richmond wrote:
> Happy New Year!!!
>
> It seems only right that readers of <a.f.c.> should post (or re-post)
> computer screw-ups that involve the change to a new year, or in some way
> are related to leap year or century or millennium changes or etc. etc.
>
> Vaguely I seem to recall something about a Microsoft music player
> hanging up (stopped working) after 1000 days because of a counter
> wrapping around to zeroes.
>
> Maybe we can also include stories involving a failure to "feed the
> watchdog timer" quickly enough.
>
> Two digit to four digit date conversion stories should be included...
> don't you think???

Not really computer-related, but before 2000 I tended to write down
dates as yy-mm-hh or yymmhh when I needed to date a letter or some
notes I'd taken on paper. So for example I'd write "990430".

For a few years /after/ 2000 I wrote year-1900 instead: "100-04-30",
"101-04-30" and so on. It didn't catch on, and I think I stopped
doing it in 2003 or so. I guess I decided I didn't need my own
personal date format.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On 7 Jan 2023 09:52:57 GMT
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:

> But recently I've had to use the Qt library's QDateTime[1] type, and
> it occurred to me that this must be how people had to work before
> someone (in the 1960s?) said "let's stop this nonsense and just count
> seconds since some T=0".

Late 60s given that the unix epoch is in 1970 (just).

> A QDateTime is:
> - a date
> - a time-of-day
> - a time zone
>
> and it's easy to get wrong. Not so much at New Year, but when you

It's impossible to get right - places like Ireland and the UK
switch timezone twice a year while most US timezones shift their offset from
UTC twice a year. Then there's the whole business of the missing/duplicated
hour as the clocks go forwards/backwards.

> start messing with the time zone, you have to remember which function
> preserves the time while shifting the time zone, and which function
> instead preserves the date and time-of-day.

Then you cross a DST boundary and all the bugs come to the surface.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

Den 01-01-2023 kl. 05:35 skrev Charles Richmond:
> Happy New Year!!!
>
> It seems only right that readers of <a.f.c.> should post (or re-post)
> computer screw-ups that involve the change to a new year, or in some way
> are related to leap year or century or millennium changes or etc. etc.
>
> Vaguely I seem to recall something about a Microsoft music player
> hanging up (stopped working) after 1000 days because of a counter
> wrapping around to zeroes.
>
> Maybe we can also include stories involving a failure to "feed the
> watchdog timer" quickly enough.
>
> Two digit to four digit date conversion stories should be included...
> don't you think???

Not so much a new year's issue, but I recall one system[1] which started
misbehaving increasingly erratically after a certain date.

After much head-scratching, the cause turned out to be that a certain
hard-coded table indexed by year ran out of entries, so the values used
for later years were random garbage.

[1] Name withheld to protect the guilty

/Anders, Denmark

On 2023-01-07, Anders D. Nygaard <news2012adn@gmail.com> wrote:
> Den 01-01-2023 kl. 05:35 skrev Charles Richmond:
>> Happy New Year!!!
>>
>> It seems only right that readers of <a.f.c.> should post (or re-post)
>> computer screw-ups that involve the change to a new year, or in some way
>> are related to leap year or century or millennium changes or etc. etc.
>>
>> Vaguely I seem to recall something about a Microsoft music player
>> hanging up (stopped working) after 1000 days because of a counter
>> wrapping around to zeroes.
>>
>> Maybe we can also include stories involving a failure to "feed the
>> watchdog timer" quickly enough.
>>
>> Two digit to four digit date conversion stories should be included...
>> don't you think???
>
> Not so much a new year's issue, but I recall one system[1] which started
> misbehaving increasingly erratically after a certain date.
>
> After much head-scratching, the cause turned out to be that a certain
> hard-coded table indexed by year ran out of entries, so the values used
> for later years were random garbage.
>
> [1] Name withheld to protect the guilty
>
> /Anders, Denmark

I remember something about that as well. Do not publish the name of the
guilty, as he might appear when His name is spoken.

--
greymausg@mail.com

Fe, Fi, Fo, Fum, I smell the stench of an Influencer.
Where is our money gone, Dude?

Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On 7 Jan 2023 09:52:57 GMT
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>
>> But recently I've had to use the Qt library's QDateTime[1] type, and
>> it occurred to me that this must be how people had to work before
>> someone (in the 1960s?) said "let's stop this nonsense and just count
>> seconds since some T=0".
>
> Late 60s given that the unix epoch is in 1970 (just).
>
>> A QDateTime is:
>> - a date
>> - a time-of-day
>> - a time zone
>>
>> and it's easy to get wrong. Not so much at New Year, but when you
>
> It's impossible to get right - places like Ireland and the UK
> switch timezone twice a year while most US timezones shift their offset from
> UTC twice a year. Then there's the whole business of the missing/duplicated
> hour as the clocks go forwards/backwards.

I think Indiana is, or was, split between two timezones; Arizona doesn’t
observe DST; based on what I saw New Years, it appears Puerto Rico is 1/2
hour ahead of New York,; China is all one timezone, and there’s lots more
of such F*ckishness.

>
>> start messing with the time zone, you have to remember which function
>> preserves the time while shifting the time zone, and which function
>> instead preserves the date and time-of-day.
>
> Then you cross a DST boundary and all the bugs come to the surface.
>

--
Pete

On 2023-01-08, Peter Flass <peter_flass@yahoo.com> wrote:

> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>
>> On 7 Jan 2023 09:52:57 GMT
>> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>>
>>> But recently I've had to use the Qt library's QDateTime[1] type, and
>>> it occurred to me that this must be how people had to work before
>>> someone (in the 1960s?) said "let's stop this nonsense and just count
>>> seconds since some T=0".
>>
>> Late 60s given that the unix epoch is in 1970 (just).
>>
>>> A QDateTime is:
>>> - a date
>>> - a time-of-day
>>> - a time zone
>>>
>>> and it's easy to get wrong. Not so much at New Year, but when you
>>
>> It's impossible to get right - places like Ireland and the UK
>> switch timezone twice a year while most US timezones shift their offset from
>> UTC twice a year. Then there's the whole business of the missing/duplicated
>> hour as the clocks go forwards/backwards.
>
> I think Indiana is, or was, split between two timezones; Arizona doesn’t
> observe DST; based on what I saw New Years, it appears Puerto Rico is 1/2
> hour ahead of New York,; China is all one timezone, and there’s lots more
> of such F*ckishness.

Saskatchewan doesn't observe DST as well. Newfoundland and Labrador are
(is?) half an hour ahead of Halifax.

>>> start messing with the time zone, you have to remember which function
>>> preserves the time while shifting the time zone, and which function
>>> instead preserves the date and time-of-day.
>>
>> Then you cross a DST boundary and all the bugs come to the surface.

I think the best thing would be to eliminate DST entirely. No more
semi-annual clock changes, no subtle bugs, and fewer road accidents
due to people's circadian rhythm being disturbed. Unfortunately,
here on the west coast of North America, most people are pushing
to make DST permanent. So much for the sun being overhead at noon.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On Sun, 08 Jan 2023 06:39:52 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

> I think the best thing would be to eliminate DST entirely. No more
> semi-annual clock changes, no subtle bugs, and fewer road accidents
> due to people's circadian rhythm being disturbed. Unfortunately,
> here on the west coast of North America, most people are pushing
> to make DST permanent. So much for the sun being overhead at noon.

Go the whole hog and switch to UTC worldwide and accept that people
work, eat, sleep etc. at different times.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

On 2023-01-08, Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2023-01-08, Peter Flass <peter_flass@yahoo.com> wrote:
>
>> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>
>>> On 7 Jan 2023 09:52:57 GMT
>>> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>>>
>>>> But recently I've had to use the Qt library's QDateTime[1] type, and
>>>> it occurred to me that this must be how people had to work before
>>>> someone (in the 1960s?) said "let's stop this nonsense and just count
>>>> seconds since some T=0".
>>>
>>> Late 60s given that the unix epoch is in 1970 (just).
>>>
>>>> A QDateTime is:
>>>> - a date
>>>> - a time-of-day
>>>> - a time zone
>>>>
>>>> and it's easy to get wrong. Not so much at New Year, but when you
>>>
>>> It's impossible to get right - places like Ireland and the UK
>>> switch timezone twice a year while most US timezones shift their offset from
>>> UTC twice a year. Then there's the whole business of the missing/duplicated
>>> hour as the clocks go forwards/backwards.
>>
>> I think Indiana is, or was, split between two timezones; Arizona doesn’t
>> observe DST; based on what I saw New Years, it appears Puerto Rico is 1/2
>> hour ahead of New York,; China is all one timezone, and there’s lots more
>> of such F*ckishness.
>
> Saskatchewan doesn't observe DST as well. Newfoundland and Labrador are
> (is?) half an hour ahead of Halifax.
>
>>>> start messing with the time zone, you have to remember which function
>>>> preserves the time while shifting the time zone, and which function
>>>> instead preserves the date and time-of-day.
>>>
>>> Then you cross a DST boundary and all the bugs come to the surface.
>
> I think the best thing would be to eliminate DST entirely. No more
> semi-annual clock changes, no subtle bugs, and fewer road accidents
> due to people's circadian rhythm being disturbed. Unfortunately,
> here on the west coast of North America, most people are pushing
> to make DST permanent. So much for the sun being overhead at noon.
>

But, But, that would mean making a decision

--
greymausg@mail.com

Fe, Fi, Fo, Fum, I smell the stench of an Influencer.
Where is our money gone, Dude?

On 2023-01-08, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Sun, 08 Jan 2023 06:39:52 GMT
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>
>> I think the best thing would be to eliminate DST entirely. No more
>> semi-annual clock changes, no subtle bugs, and fewer road accidents
>> due to people's circadian rhythm being disturbed. Unfortunately,
>> here on the west coast of North America, most people are pushing
>> to make DST permanent. So much for the sun being overhead at noon.
>
> Go the whole hog and switch to UTC worldwide and accept that people
> work, eat, sleep etc. at different times.
>

Its bad enough having relatives mailing photos from the beach in
Australia at Christmas without that. (forgetting people swimming at the
40ft in Dublin). remember yesterday was Christmas day in Russia.

--
greymausg@mail.com

Fe, Fi, Fo, Fum, I smell the stench of an Influencer.
Where is our money gone, Dude?

On So 08 Jan 2023 at 08:46, Ahem A Rivet's Shot <steveo@eircom.net> wrote:

> On Sun, 08 Jan 2023 06:39:52 GMT
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>
>> I think the best thing would be to eliminate DST entirely. No more
>> semi-annual clock changes, no subtle bugs, and fewer road accidents
>> due to people's circadian rhythm being disturbed. Unfortunately,
>> here on the west coast of North America, most people are pushing
>> to make DST permanent. So much for the sun being overhead at noon.
>
> Go the whole hog and switch to UTC worldwide and accept that people
> work, eat, sleep etc. at different times.

Yes, but that would be rational - so no chance.

'Andreas

On Sat, 7 Jan 2023 17:55:55 -0700, Peter Flass <peter_flass@yahoo.com>
wrote:
>Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>> On 7 Jan 2023 09:52:57 GMT
>> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>>
>>> But recently I've had to use the Qt library's QDateTime[1] type, and
>>> it occurred to me that this must be how people had to work before
>>> someone (in the 1960s?) said "let's stop this nonsense and just count
>>> seconds since some T=0".
>>
>> Late 60s given that the unix epoch is in 1970 (just).
>>
>>> A QDateTime is:
>>> - a date
>>> - a time-of-day
>>> - a time zone
>>>
>>> and it's easy to get wrong. Not so much at New Year, but when you
>>
>> It's impossible to get right - places like Ireland and the UK
>> switch timezone twice a year while most US timezones shift their offset from
>> UTC twice a year. Then there's the whole business of the missing/duplicated
>> hour as the clocks go forwards/backwards.
>
>I think Indiana is, or was, split between two timezones; Arizona doesn’t
>observe DST; based on what I saw New Years, it appears Puerto Rico is 1/2
>hour ahead of New York,; China is all one timezone, and there’s lots more
>of such F*ckishness.

I was looking online at a time zone map a few years ago, and smaller
countries around Pakistan are a half hour ahead of the surrounding
countries. seems silly to me.

Can't find the one I saw years ago, but this page mentions some
countries are 30 and 45 minutes ahead of others nearby. Also
explanations of DST, etc.

https://www.timeanddate.com/time/current-number-time-zones.html
--
Jim

On 2023-01-08, greymaus <greymaus@dmaus.org> wrote:

> On 2023-01-08, Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>
>> I think the best thing would be to eliminate DST entirely. No more
>> semi-annual clock changes, no subtle bugs, and fewer road accidents
>> due to people's circadian rhythm being disturbed. Unfortunately,
>> here on the west coast of North America, most people are pushing
>> to make DST permanent. So much for the sun being overhead at noon.
>
> But, But, that would mean making a decision

That's the frustrating part - the governments of British Columbia,
Washington, Oregon, and California are considering making such a
decision. I mentioned it to a few people at the office and a lot
of them are in favour. They'd rather have a dark morning, I guess.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On 2023-01-08, Ahem A Rivet's Shot <steveo@eircom.net> wrote:

> On Sun, 08 Jan 2023 06:39:52 GMT
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>
>> I think the best thing would be to eliminate DST entirely. No more
>> semi-annual clock changes, no subtle bugs, and fewer road accidents
>> due to people's circadian rhythm being disturbed. Unfortunately,
>> here on the west coast of North America, most people are pushing
>> to make DST permanent. So much for the sun being overhead at noon.
>
> Go the whole hog and switch to UTC worldwide and accept that people
> work, eat, sleep etc. at different times.

Aviation already uses UTC, although anything that crosses time zones
would benefit.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.