On 3/3/2022 5:42 PM, James Kuyper wrote:
> On 3/3/22 16:45, Vir Campestris wrote:
> ...
>> We've been here before. Y2K problem.
>>
>> Some people hit it in 1990 with 10 year contracts.
>>
>> Almost nobody hit in 2000.
>>
>> A few did, but the world didn't end.
>>
>> There will be work to do, but WTH it's 16 years away.
>
> I had dozens of saved e-mails at work which were sent during the first
> week of 2000, which have incorrectly formatted time stamps. It was only
> a minor inconvenience - but they are proof that not enough money had
> been spent to fix all of the problems - and these were messages sent and
> received by US government mail servers.
> I only saw two other Y2K bugs. One of them occurred, ironically enough,
> on a web site devoted to keeping track of detected Y2K bugs: For several
> hours after midnight it still reported something like "As of January 1,
> 1900 at 07:00, no Y2K bugs have yet been reported."

That is hilarious.

Lynn

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> I only saw two other Y2K bugs. One of them occurred, ironically enough,
> on a web site devoted to keeping track of detected Y2K bugs: For several
> hours after midnight it still reported something like "As of January 1,
> 1900 at 07:00, no Y2K bugs have yet been reported."

Nice story.

I only saw one "in the wild". The university had to briefly stop
registering PhD students in early 1995 because the normal latest
completion date was five years after registration, and instead of
getting welcome letters the students were being told their thesis was 95
years overdue.

--
Ben.

On 3/3/2022 7:17 PM, Manfred wrote:
> On 3/3/2022 8:22 PM, David Brown wrote:
>> On 03/03/2022 01:18, Keith Thompson wrote:
> [...]
>>>
>>> So you want to require electricity providers to send high-resolution
>>> time information via AC current, in a way that is guaranteed to be
>>> usable by any device plugged directly or indirectly into a wall socket,
>>> and that absolutely will not interfere with any existing devices.
>>> (Maybe that's possible; I don't know.)
>>
>> No, it is not /remotely/ possible - not technically possible, nor, I
>> suspect, legally.
>>
>
> This is OT, but for the sake of argument, domestic power meters already
> exchange digital signals with distribution stations, so I guess it is
> not that impossible - similarly to how it is nowadays possible to
> transfer Gbits/s on a copper pair, something that seemed fairly
> unfeasible until it wasn't.
> How useful it would be would be quite questionable, I agree.

The two ??? million electric power meters in the Houston Metropolitan
area use directional radio wifi as their primary carrier and cellular
wifi as their backup carrier. Their radio towers are quite saturated
already since they now poll the smart meters every five minutes.

Lynn

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 3/3/22 16:45, Vir Campestris wrote:
> ...
>> We've been here before. Y2K problem.
>>
>> Some people hit it in 1990 with 10 year contracts.
>>
>> Almost nobody hit in 2000.
>>
>> A few did, but the world didn't end.
>>
>> There will be work to do, but WTH it's 16 years away.
>
> I had dozens of saved e-mails at work which were sent during the first
> week of 2000, which have incorrectly formatted time stamps. It was only
> a minor inconvenience - but they are proof that not enough money had
> been spent to fix all of the problems - and these were messages sent and
> received by US government mail servers.
> I only saw two other Y2K bugs. One of them occurred, ironically enough,
> on a web site devoted to keeping track of detected Y2K bugs: For several
> hours after midnight it still reported something like "As of January 1,
> 1900 at 07:00, no Y2K bugs have yet been reported."

I saw a Y2.001K bug. We used a bug tracking system (Remedy) that
used Unix time_t values as timestamps -- but it stored them as text
in a 9-character string. One billion seconds after the epoch, at
Sun 2001-09-09 01:46:40 UTC, it started dropping the last digit. Its
idea of the current time jumped back to Sat 1973-03-03 09:46:40 UTC,
advancing at 10% of real time. (It was fixed within a few days.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
> I only saw two other Y2K bugs. One of them occurred, ironically enough,
> on a web site devoted to keeping track of detected Y2K bugs: For several
> hours after midnight it still reported something like "As of January 1,
> 1900 at 07:00, no Y2K bugs have yet been reported."

Well, it was technically correct.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 2022-03-04, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> [...]
>> I only saw two other Y2K bugs. One of them occurred, ironically enough,
>> on a web site devoted to keeping track of detected Y2K bugs: For several
>> hours after midnight it still reported something like "As of January 1,
>> 1900 at 07:00, no Y2K bugs have yet been reported."
>
> Well, it was technically correct.

Not grammatically though; you need the "had" past participle
to make it clear that January 1, 1900 is in the past, rather
than now, thereby evoking the technically correct meaning.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 2022-02-28, Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> "Year 2038 problem is still alive and well" by CookiePLMonster
> https://cookieplmonster.github.io/2022/02/17/year-2038-problem/
>
> "Year 2038 problem? Wasn’t that supposed to be solved once and for all
> years ago? Not quite."

We should adopt a cyclic three digit year for some contexts. The main
problem with two digit years is that a century is too small of a time
span, which causes ambiguities, such as that someone born in `19 could
be a toddler, or 103 years old.

A three-digit year will fix most such things. 919 versus 019. Only if
you have contracts that span most of a millennium and such do you have
issues. For most human activities, it's sufficient, easily understood,
and free of issues. It never overflows; it doesn't accumulate more and
more precision with advancing time, always requiring the same amount of
storage. Arithmetic is easy. If you have two dates, d1 and d0, if d1 -
d0 <= 500y, then d0 is considered in the past. For instance, year 853 is
considered in the past relative to year 159.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

In article <svrq45$71k$1@dont-email.me>,
Lynn McGuire <lynnmcguire5@gmail.com> wrote:
....
>The two ??? million electric power meters in the Houston Metropolitan
>area use directional radio wifi as their primary carrier and cellular
>wifi as their backup carrier. Their radio towers are quite saturated
>already since they now poll the smart meters every five minutes.

Yeah, but that's Texas.

We now know (if we didn't already) with absolute certainty that Texas is
weird and weirdly incompetent when it comes to electricity distribution and
related topics.

So, I'm not surprised they do it some weird way. Probably do it that way
just to "own the libs".

--
Those on the right constantly remind us that America is not a
democracy; now they claim that Obama is a threat to democracy.

On 04/03/2022 02:17, Manfred wrote:
> On 3/3/2022 8:22 PM, David Brown wrote:
>> On 03/03/2022 01:18, Keith Thompson wrote:
> [...]
>>>
>>> So you want to require electricity providers to send high-resolution
>>> time information via AC current, in a way that is guaranteed to be
>>> usable by any device plugged directly or indirectly into a wall socket,
>>> and that absolutely will not interfere with any existing devices.
>>> (Maybe that's possible; I don't know.)
>>
>> No, it is not /remotely/ possible - not technically possible, nor, I
>> suspect, legally.
>>
>
> This is OT, but for the sake of argument, domestic power meters already
> exchange digital signals with distribution stations, so I guess it is
> not that impossible - similarly to how it is nowadays possible to
> transfer Gbits/s on a copper pair, something that seemed fairly
> unfeasible until it wasn't.
> How useful it would be would be quite questionable, I agree.

It is certainly possible to transmit information over an AC line. But
it is difficult, and gets very difficult when the communication must
pass over fuses, transformers, connection boxes and long lines. So you
can get modules for communication over power lines within a house -
these work reasonably well, but speed and distance is highly variable.
(And as you can imagine, the price is massively greater than a
microdollar!).

Transmission from an automatic power meter towards an AC distribution
transformer in a street /can/ be done, in some cases. It will depend
somewhat on the topology of the power system, the distances, the quality
of the cables, and many other factors. (Transmitting from that
transformer further up towards the power providers is unrealistic - the
distances are too high, the power and voltages too high, and the
impedance is all wrong.)

Solutions for reading from automatic power meters vary. Some try to be
real-time, others sum up totals for a month. Some communicate directly
back to the power company using cellular modems, or by connecting to a
household Wifi or Ethernet. Some use low-range radio to communicate
with a central collector that has network connection upstream. Some are
read by short-range radio from a van that drives through the
neighbourhood. And yes, some communicate over the supply lines into the
house.

On 04/03/2022 09:18, David Brown wrote:
> On 04/03/2022 02:17, Manfred wrote:
>> On 3/3/2022 8:22 PM, David Brown wrote:
>>> On 03/03/2022 01:18, Keith Thompson wrote:
>> [...]
>>>>
>>>> So you want to require electricity providers to send high-resolution
>>>> time information via AC current, in a way that is guaranteed to be
>>>> usable by any device plugged directly or indirectly into a wall socket,
>>>> and that absolutely will not interfere with any existing devices.
>>>> (Maybe that's possible; I don't know.)
>>>
>>> No, it is not /remotely/ possible - not technically possible, nor, I
>>> suspect, legally.
>>>
>>
>> This is OT, but for the sake of argument, domestic power meters already
>> exchange digital signals with distribution stations, so I guess it is
>> not that impossible - similarly to how it is nowadays possible to
>> transfer Gbits/s on a copper pair, something that seemed fairly
>> unfeasible until it wasn't.
>> How useful it would be would be quite questionable, I agree.
>
> It is certainly possible to transmit information over an AC line. But
> it is difficult, and gets very difficult when the communication must
> pass over fuses, transformers, connection boxes and long lines.

Demon Internet used to transmit internet data along high voltage
distribution cables in the UK.

I don't know how it would work to connect individual consumers. But the
suggestion was to broadcast a timing signal, which sounds lot simpler;
you said it wasn't possible.

(However using existing radio signals for that, eg. MSF, is a better idea.)

In comp.lang.c++ Kaz Kylheku <480-992-1380@kylheku.com> wrote:
> We should adopt a cyclic three digit year for some contexts. The main
> problem with two digit years is that a century is too small of a time
> span, which causes ambiguities, such as that someone born in `19 could
> be a toddler, or 103 years old.

It's indeed curious how common it is to express dates, such as dates
of birth, with a two-digit year. Some countries have, for example,
date-of-birth based personal IDs, and the date is almost invariably
of the form 010203 where the last two digits are the year.

Given that such IDs were most commonly adopted in the earlier half
of the 1900's it might have made sense back then, but once the millenium
drew closer it became more and more of a problem to distinguish between
newly born people and people who had their 100th birthday.

For example in Finland the format of personal IDs is DDMMYY-xxxx
where the xxxx is a four-character unique code consisting of letters
and numbers. To solve the millenium problem, what they decided to do
was that for people born in 2000 and after that - would be a + instead,
which feels like quite a kludge.

I think it would have been better to just have them have IDs of the
form DDMMYYYY-xxxx. Would have been much clearer and nicer-looking.

On Fri, 4 Mar 2022 09:56:03 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>In comp.lang.c++ Kaz Kylheku <480-992-1380@kylheku.com> wrote:
>> We should adopt a cyclic three digit year for some contexts. The main
>> problem with two digit years is that a century is too small of a time
>> span, which causes ambiguities, such as that someone born in `19 could
>> be a toddler, or 103 years old.
>
>It's indeed curious how common it is to express dates, such as dates
>of birth, with a two-digit year. Some countries have, for example,
>date-of-birth based personal IDs, and the date is almost invariably
>of the form 010203 where the last two digits are the year.

I think the issue is that in most non IT cases the century doesn't matter.
People just know that if a young man gives his year of birth as 99 or 01 its not
going to be 1899 or 1901. Unfortunately this indifference to the century
carried over to programmers who then only used 2 digits in their code. This
*might* have just been valid back in the 50s when every byte really did
matter but nobody after the 60s really had any excuse to do this.

At least the unix 4 byte date had a reasonable excuse that back in the early
70s when unix was designed even 32 bit machines were stuff of the future
for anything except high end mainframes like the System 360 et al.

On 04/03/2022 10:50, Bart wrote:
> On 04/03/2022 09:18, David Brown wrote:
>> On 04/03/2022 02:17, Manfred wrote:
>>> On 3/3/2022 8:22 PM, David Brown wrote:
>>>> On 03/03/2022 01:18, Keith Thompson wrote:
>>> [...]
>>>>>
>>>>> So you want to require electricity providers to send high-resolution
>>>>> time information via AC current, in a way that is guaranteed to be
>>>>> usable by any device plugged directly or indirectly into a wall
>>>>> socket,
>>>>> and that absolutely will not interfere with any existing devices.
>>>>> (Maybe that's possible; I don't know.)
>>>>
>>>> No, it is not /remotely/ possible - not technically possible, nor, I
>>>> suspect, legally.
>>>>
>>>
>>> This is OT, but for the sake of argument, domestic power meters already
>>> exchange digital signals with distribution stations, so I guess it is
>>> not that impossible - similarly to how it is nowadays possible to
>>> transfer Gbits/s on a copper pair, something that seemed fairly
>>> unfeasible until it wasn't.
>>> How useful it would be would be quite questionable, I agree.
>>
>> It is certainly possible to transmit information over an AC line.  But
>> it is difficult, and gets very difficult when the communication must
>> pass over fuses, transformers, connection boxes and long lines.
>
> Demon Internet used to transmit internet data along high voltage
> distribution cables in the UK.
>
> I don't know how it would work to connect individual consumers. But the
> suggestion was to broadcast a timing signal, which sounds lot simpler;
> you said it wasn't possible.
>

You can do some kinds of power line communication over some kinds of
lines. The suggestion was to do it over /all/ lines, in the same way -
at high enough speeds to get microsecond accuracy.

> (However using existing radio signals for that, eg. MSF, is a better idea.)
>

Yes, radio is a vastly better way to handle time signals. AFAIK there
used to be broadcast time signals in some places, but I don't think
these are used any more. GPS contains high accuracy time signals for
those that need it.

But any kind of data reception - radio, power-line, whatever - costs
money, power, space and complexity at the receiving end. Counting AC
cycles is by far the cheapest and simplest solution when you are plugged
in, and is stable over the long term but has no absolute reference.
Even that, however, costs /many/ orders of magnitude more than Siri was
suggesting.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

David Brown wrote:
> [...]
> But any kind of data reception - radio, power-line, whatever - costs
> money, power, space and complexity at the receiving end. Counting AC
> cycles is by far the cheapest and simplest solution when you are plugged
> in, and is stable over the long term but has no absolute reference.

And my microwave doesn't need an absolute reference either.

Honestly though, even using the AC line sounds like its adding
complexity for little (or no) benefit to my oven/microwave/etc. Also,
how's it gonna handle different line frequency? As a manufacturer, am I
gonna need half a dozen different designs of the same product to
accommodate line frequency?

Sounds "expensive" -- at least compared to one globally ubiquitous
design that bases the "time" display off a dead simple counter/timer
that's probably already available on the microcontroller.

.... or have I completely lost the plot on this discussion now?

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIiIwEACgkQbWVw5Uzn
KGDOmhAAj48J/OTi29aWodfOLNZXJdNeKWUo8SEeARRxP9GpovinaN36oKb0DnPG
qVbgiS1LgvrHmY+oYnfueR3W/ILwD6gI0fOeXw12eP7D4AsiahF4PZVAjtXVHP4q
km7gPiT8wzQTG0Zy0i/U0dzuVmkDzsbmKaF79h5Yj9YMOEj6zd3NA3ElSB2+GkmR
N9zFw8QmaymA5TWJsyC2p1AqZC91qTNa6MnO73GjIAdb+yTIpRtT2Pi3tA6HfpRU
k3mt4ZgbFQdkcXeURH8zXM1zpeaKQ4TatmsX6ctBf/YhuJ8AQQvCa5SA8PCnrMQC
klUTZ08C0uaJBOd7C4adCjfFs31cEH4jmAYlFk46isCEW8rTkqXjrCdBxYOSmJIV
IBevMFzigVgA2KS6EB9xOeTu9pVfSzzi41suvSe6QO5QpsJEWCTZMG7witGd86Pr
jKY26pEy5l/yAwas2UUSGddqRl986/nkm4R05B3Ef/m+ZYTv8zCxozI2IisSyYIu
jK4A48f54dqA5xKDJn6au8DHyTzfVr8gE1xDKwth8MFcpOLYMN+QxCqrxYT0KrZ2
PIAaQMPBk+mJiL8Xo+LhuXd1O9KZz/fwhK3kBIeJ2s3JizTF85jzFkacuvpkEF1k
jBuVaaSe/ycAJatm9+ISdV/fCxFJHV2Z/T2ctpHtK2X9OkTVE14=
=arNB
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 04/03/2022 15:31, Dan Purgert wrote:
> David Brown wrote:
>> [...]
>> But any kind of data reception - radio, power-line, whatever - costs
>> money, power, space and complexity at the receiving end. Counting AC
>> cycles is by far the cheapest and simplest solution when you are plugged
>> in, and is stable over the long term but has no absolute reference.
>
> And my microwave doesn't need an absolute reference either.
>
> Honestly though, even using the AC line sounds like its adding
> complexity for little (or no) benefit to my oven/microwave/etc. Also,
> how's it gonna handle different line frequency? As a manufacturer, am I
> gonna need half a dozen different designs of the same product to
> accommodate line frequency?

There are only two frequencies used - 50 Hz and 60 Hz. It's not hard to
make automatic detection of which of these you are seeing, as you always
have some kind of frequency reference for your microcontroller.

>
> Sounds "expensive" -- at least compared to one globally ubiquitous
> design that bases the "time" display off a dead simple counter/timer
> that's probably already available on the microcontroller.
>
>
> ... or have I completely lost the plot on this discussion now?
>
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

David Brown wrote:
> On 04/03/2022 15:31, Dan Purgert wrote:
>>
>> Honestly though, even using the AC line sounds like its adding
>> complexity for little (or no) benefit to my oven/microwave/etc. Also,
>> how's it gonna handle different line frequency? As a manufacturer, am I
>> gonna need half a dozen different designs of the same product to
>> accommodate line frequency?
>
> There are only two frequencies used - 50 Hz and 60 Hz. It's not hard to
> make automatic detection of which of these you are seeing, as you always
> have some kind of frequency reference for your microcontroller.

Whoops, that was supposed to be "multiple", not "half a dozen". Thought
process collisions are just wonderful, aren't they.

I guess we can say I've lost the plot somewhere then -- I just can't
piece together how this would improve "timekeeping" on a device plugged
into the mains.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIiNBQACgkQbWVw5Uzn
KGAORg/+NhipHiTNl+BYwzq4iRiHvGdsixx43bux418n6/I89gcSM5WRZttEgfM6
mdC1Q6TFEusaUH56yYz3S9ZEkdpw7PohaNtkXjNufpP964mtesY+Ii6nFYQL/J2i
AomETFXvMvRtMtSnc9Qly8F55Bp4pYEwZ9E09OWpr3Cuv8t7z/z/zk5vVMTzE1lm
JiM33X8L3WCvtLHKd2/GkPiNNEQfdA5kkUiEU5U30/R7nSImpAVeM4CmEPl9my7S
FFa7rXVtLx2EzUVj2zIafVFuaVzozK2kKu6Q5+TgfCYHriVkyI+82gItARgsCp2M
hqLjIHJsvafpKLvJ8bA/+f3B65bGOxzVO4bIqa/lHUBRVhm+jm0ZNT4HAQZq2d4d
kVRvs/6C4GiiABlCIX/PEBYOS4d0yrrHHrj2ClmhGJLOoQIZ/ZY4B8KcObZ8ipju
COWuLXNUuDlCcQqB0fZqkSfUcNr+Cdf+oZNMxgUtR65W1fUkNoDFjsTZIHKZ0VS1
brW1d/5frB9Cme+L28YVBh+dkDKATelMDw/g+mehfAft7u3NnHkLBokAg0OETCo3
YntKkh3uMLUgl12NbjaJpP5wCsFoDSqTy3Ij2KV5h+ORhMafCWhLSrh+yiYAJJA+
jWjdyoBb8BH3KZC+5/761tIEvCI06WHElOSQpFhjSgcJpa9Ub9k=
=E5+f
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>On 3/3/22 16:45, Vir Campestris wrote:
>...
>> We've been here before. Y2K problem.
>>
>> Some people hit it in 1990 with 10 year contracts.
>>
>> Almost nobody hit in 2000.
>>
>> A few did, but the world didn't end.
>>
>> There will be work to do, but WTH it's 16 years away.
>
>I had dozens of saved e-mails at work which were sent during the first
>week of 2000, which have incorrectly formatted time stamps. It was only
>a minor inconvenience - but they are proof that not enough money had
>been spent to fix all of the problems - and these were messages sent and
>received by US government mail servers.
>I only saw two other Y2K bugs. One of them occurred, ironically enough,
>on a web site devoted to keeping track of detected Y2K bugs: For several
>hours after midnight it still reported something like "As of January 1,
>1900 at 07:00, no Y2K bugs have yet been reported."

A friend of my worked for Tandem Computers back in the 1990's when they
had a time issue in the Non-Stop systems which triggered at midnight;
as each timezone on the planet reached midnight, the systems would
stop. He had a firmware patch prepared and shipped the the customers before
the bug hit Western Europe.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
>> I only saw two other Y2K bugs. One of them occurred, ironically enough,
>> on a web site devoted to keeping track of detected Y2K bugs: For several
>> hours after midnight it still reported something like "As of January 1,
>> 1900 at 07:00, no Y2K bugs have yet been reported."
>
>Nice story.
>
>I only saw one "in the wild".

For what it is worth, we started preparing for Y2K in 1985 for
the Burroughs mainframe MCP - there were no problems when the
year rolled over to 2000 (the system had used two-digit years
exclusively up to that point - the problem was deferred to 2050
by interpreting two digit years less than 50 as 21st century
anjd two digit years 50 or more as 19th century)

The final system was decomissioned in the mid 2010s.

Manfred <noname@add.invalid> writes:
>On 3/3/2022 8:22 PM, David Brown wrote:
>> On 03/03/2022 01:18, Keith Thompson wrote:
>[...]
>>>
>>> So you want to require electricity providers to send high-resolution
>>> time information via AC current, in a way that is guaranteed to be
>>> usable by any device plugged directly or indirectly into a wall socket,
>>> and that absolutely will not interfere with any existing devices.
>>> (Maybe that's possible; I don't know.)
>>
>> No, it is not /remotely/ possible - not technically possible, nor, I
>> suspect, legally.
>>
>
>This is OT, but for the sake of argument, domestic power meters already
>exchange digital signals with distribution stations, so I guess it is
>not that impossible - similarly to how it is nowadays possible to

They don't do it over the power lines. It's OTA, similar to
mobile phones.

David Brown <david.brown@hesbynett.no> writes:
>On 04/03/2022 15:31, Dan Purgert wrote:
>> David Brown wrote:
>>> [...]
>>> But any kind of data reception - radio, power-line, whatever - costs
>>> money, power, space and complexity at the receiving end. Counting AC
>>> cycles is by far the cheapest and simplest solution when you are plugged
>>> in, and is stable over the long term but has no absolute reference.
>>
>> And my microwave doesn't need an absolute reference either.
>>
>> Honestly though, even using the AC line sounds like its adding
>> complexity for little (or no) benefit to my oven/microwave/etc. Also,
>> how's it gonna handle different line frequency? As a manufacturer, am I
>> gonna need half a dozen different designs of the same product to
>> accommodate line frequency?
>
>There are only two frequencies used - 50 Hz and 60 Hz. It's not hard to
>make automatic detection of which of these you are seeing, as you always
>have some kind of frequency reference for your microcontroller.

Although with modern switching power supplies, the AC mains frequency is
pretty much irrelevent and certainly not visible downstream of the
power supply.

On 2022-03-04 David Brown wrote in comp.lang.c:
> On 04/03/2022 10:50, Bart wrote:

>> (However using existing radio signals for that, eg. MSF, is a better idea.)
>>
>
> Yes, radio is a vastly better way to handle time signals. AFAIK there
> used to be broadcast time signals in some places, but I don't think
> these are used any more. GPS contains high accuracy time signals for
> those that need it.

DCF77 is still operational and widely used:
https://en.wikipedia.org/wiki/DCF77
The transmitter is in Germany and covers a large part of Europe.

You can buy all sorts of clocks here that run on that time signal.
Always on time and automatic daylight saving time.

--
Stef

"If a computer can't directly address all the RAM you can use, it's just a toy."
-- anonymous comp.sys.amiga posting, non-sequitir

Dan Purgert <dan@djph.net> wrote:

> I guess we can say I've lost the plot somewhere then -- I just can't
> piece together how this would improve "timekeeping" on a device
> plugged into the mains.

The mains frequency is a rather good timebase: the base frequency (be it
50 or 60 Hz) is very rigidly maintained, because otherwise the whole
interconnected power network would very quickly fall apart.

https://www.mainsfrequency.com/gridtime.php
--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

On 3/4/2022 1:22 AM, Kaz Kylheku wrote:
> On 2022-02-28, Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>> "Year 2038 problem is still alive and well" by CookiePLMonster
>> https://cookieplmonster.github.io/2022/02/17/year-2038-problem/
>>
>> "Year 2038 problem? Wasn’t that supposed to be solved once and for all
>> years ago? Not quite."
>
> We should adopt a cyclic three digit year for some contexts. The main
> problem with two digit years is that a century is too small of a time
> span, which causes ambiguities, such as that someone born in `19 could
> be a toddler, or 103 years old.
>
> A three-digit year will fix most such things. 919 versus 019. Only if
> you have contracts that span most of a millennium and such do you have
> issues. For most human activities, it's sufficient, easily understood,
> and free of issues. It never overflows; it doesn't accumulate more and
> more precision with advancing time, always requiring the same amount of
> storage. Arithmetic is easy. If you have two dates, d1 and d0, if d1 -
> d0 <= 500y, then d0 is considered in the past. For instance, year 853 is
> considered in the past relative to year 159.

At that point, why not use all four year digits ?

Lynn

On 2022-03-04, Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> On 3/4/2022 1:22 AM, Kaz Kylheku wrote:
>> On 2022-02-28, Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>> "Year 2038 problem is still alive and well" by CookiePLMonster
>>> https://cookieplmonster.github.io/2022/02/17/year-2038-problem/
>>>
>>> "Year 2038 problem? Wasn’t that supposed to be solved once and for all
>>> years ago? Not quite."
>>
>> We should adopt a cyclic three digit year for some contexts. The main
>> problem with two digit years is that a century is too small of a time
>> span, which causes ambiguities, such as that someone born in `19 could
>> be a toddler, or 103 years old.
>>
>> A three-digit year will fix most such things. 919 versus 019. Only if
>> you have contracts that span most of a millennium and such do you have
>> issues. For most human activities, it's sufficient, easily understood,
>> and free of issues. It never overflows; it doesn't accumulate more and
>> more precision with advancing time, always requiring the same amount of
>> storage. Arithmetic is easy. If you have two dates, d1 and d0, if d1 -
>> d0 <= 500y, then d0 is considered in the past. For instance, year 853 is
>> considered in the past relative to year 159.
>
> At that point, why not use all four year digits ?

Because it is ambiguous; a four-year digit currently doesn't say "I am a
special year representation that is reduced modulo 10000", and won't be
correctly treated as such. A three-digit year immediately says, "there
is something weird about me; I require special handling".

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

In article <874k4d8ojg.fsf@tigger.extechop.net>,
om@iki.fi (Otto J. Makela) wrote:

> The mains frequency is a rather good timebase: the base frequency (be it
> 50 or 60 Hz) is very rigidly maintained, because otherwise the whole
> interconnected power network would very quickly fall apart.

How can that be true? All the experts are chiming in that it's
impossible to have a stanardised and rigidly adhered to anything
about the grid.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed