On 01/03/2022 16:23, Bonita Montero wrote:

>         static
>         uint64_t const alignas(CL_SIZE) monthOffsets[2][12 + 1] =
>         {
>             { 0 * DAY, 31 * DAY, 59 * DAY, 90 * DAY, 120 * DAY, 151 *
> DAY, 181 * DAY, 212 * DAY, 243 * DAY, 273 * DAY, 304 * DAY, 334 * DAY,
> 999 * DAY },
>             { 0 * DAY, 31 * DAY, 60 * DAY, 91 * DAY, 121 * DAY, 152 *
> DAY, 182 * DAY, 213 * DAY, 244 * DAY, 274 * DAY, 305 * DAY, 335 * DAY,
> 999 * DAY }
>         };
>         uint64_t const *pMonthOffsets = monthOffsets[leapYear];

>     uint8_t const alignas(CL_SIZE) montLengths[2][1 + 12] =
>     {
>         { 0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
>         { 0, 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
>     };

>     static
>     uint16_t const alignas(CL_SIZE) monthOffsets[2][1 + 12] =
>     {
>         { 0, 0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334 },
>         { 0, 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335 }
>     };

You need to specify the days in each month 6 times?

And DAY specified 26 times instead of just once to multiple the days?

There must be a dozen ways of doing that more efficiently and more
centralised. And what happened to C++'s famous constexpr?

Am 01.03.2022 um 18:33 schrieb Bart:
> On 01/03/2022 16:23, Bonita Montero wrote:
>
>>          static
>>          uint64_t const alignas(CL_SIZE) monthOffsets[2][12 + 1] =
>>          {
>>              { 0 * DAY, 31 * DAY, 59 * DAY, 90 * DAY, 120 * DAY, 151 *
>> DAY, 181 * DAY, 212 * DAY, 243 * DAY, 273 * DAY, 304 * DAY, 334 * DAY,
>> 999 * DAY },
>>              { 0 * DAY, 31 * DAY, 60 * DAY, 91 * DAY, 121 * DAY, 152 *
>> DAY, 182 * DAY, 213 * DAY, 244 * DAY, 274 * DAY, 305 * DAY, 335 * DAY,
>> 999 * DAY }
>>          };
>>          uint64_t const *pMonthOffsets = monthOffsets[leapYear];
>
>>      uint8_t const alignas(CL_SIZE) montLengths[2][1 + 12] =
>>      {
>>          { 0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
>>          { 0, 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
>>      };
>
>>      static
>>      uint16_t const alignas(CL_SIZE) monthOffsets[2][1 + 12] =
>>      {
>>          { 0, 0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334 },
>>          { 0, 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335 }
>>      };
>
> You need to specify the days in each month 6 times?

This _is_ for efficiency !

> There must be a dozen ways of doing that more efficiently and
> more centralised.

There's no way to do it more efficiently. Even the binary search is
slower than a linear search on these arrays because there's only one
misprediction with a linear search.

> And what happened to C++'s famous constexpr?

Nice idea. But with constexpr I can't do search loops in my array.

On Tuesday, 1 March 2022 at 16:41:23 UTC, Scott Lurndal wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >On Tuesday, 1 March 2022 at 13:33:41 UTC, Dan Purgert wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA512
> >> Malcolm McLean wrote:
> >> > On Tuesday, 1 March 2022 at 10:47:37 UTC, David Brown wrote:
> >> >>
> >> >> Small embedded systems rarely care about the current time, never mind
> >> >> the year. Those that do, but are limited enough to not have support for
> >> >> 64-bit types, will not use time_t or any other standard C time or date
> >> >> functions - they'll handle it "manually".
> >> >>
> >> > My sister's oven contains a clock. As does my central heating controller.
> >> > Admittedly that's only two out of many microprocessors, some of which
> >> > we are doubtless unaware of even owning. But it's enough for Y2038 to
> >> > be a potential nuisance.
> >> Does the clock happen to count the year and/or reference the UNIX Epoch
> >> at all? My microwave / oven don't...
> >>
> >I don't have access to the code. But it will have a function called something like
> >query_clock(), That might return hour /minute /second, with caller responsible
> >for wrapping at midnight. Or it might return a "time in seconds since an arbitrary
> >date", in which case caller doens't need to bother about wrapping, until the
> >width of the return value overflow.
> Or far more likely, it simply maintains 4 BCD digits (two hour and two minute)
> advancing the MM by 1 every 60 seconds using a simple 60hz timer based on the
> AC frequency.
>
They're real clocks, not timers. You can check them to get the time of day.

On 01/03/2022 18:43, Malcolm McLean wrote:
> On Tuesday, 1 March 2022 at 16:41:23 UTC, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>> On Tuesday, 1 March 2022 at 13:33:41 UTC, Dan Purgert wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA512
>>>> Malcolm McLean wrote:
>>>>> On Tuesday, 1 March 2022 at 10:47:37 UTC, David Brown wrote:
>>>>>>
>>>>>> Small embedded systems rarely care about the current time, never mind
>>>>>> the year. Those that do, but are limited enough to not have support for
>>>>>> 64-bit types, will not use time_t or any other standard C time or date
>>>>>> functions - they'll handle it "manually".
>>>>>>
>>>>> My sister's oven contains a clock. As does my central heating controller.
>>>>> Admittedly that's only two out of many microprocessors, some of which
>>>>> we are doubtless unaware of even owning. But it's enough for Y2038 to
>>>>> be a potential nuisance.
>>>> Does the clock happen to count the year and/or reference the UNIX Epoch
>>>> at all? My microwave / oven don't...
>>>>
>>> I don't have access to the code. But it will have a function called something like
>>> query_clock(), That might return hour /minute /second, with caller responsible
>>> for wrapping at midnight. Or it might return a "time in seconds since an arbitrary
>>> date", in which case caller doens't need to bother about wrapping, until the
>>> width of the return value overflow.
>> Or far more likely, it simply maintains 4 BCD digits (two hour and two minute)
>> advancing the MM by 1 every 60 seconds using a simple 60hz timer based on the
>> AC frequency.
>>
> They're real clocks, not timers. You can check them to get the time of day.
>

Scott described a real clock. The method he describes is accurate - it
is a very common method. AC frequency can vary a little throughout the
day depending on load, but it is guaranteed to be within certain limits
of variation, and for the sum of the errors to be zero on average. This
makes it a better reference for time-keeping than a crystal oscillator
or other frequency reference.

Here's a clue for you - on most ovens, microwaves, etc., if there is a
power cut you need to set the time again when power is back on. You
also have to manually put the clock forwards or backwards for summer and
winter time.

The other common solution to timekeeping on embedded systems is a
battery-powered real-time clock. This is either a stand-alone chip, or
built into a microcontroller. And very often, it is a set of individual
registers for the seconds, minutes, and hours (and possibly date).

Small systems do not work with Unix epochs for displaying time and date.
The conversion, handling all the messy details of leap years or even
leap seconds, is big and slow. It could easily take a substantial
proportion of the flash space on a small microcontroller - you don't do it.

On 01/03/2022 17:30, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 01/03/2022 14:19, Malcolm McLean wrote:
>>> On Tuesday, 1 March 2022 at 10:47:37 UTC, David Brown wrote:
>>>>
>>>> Small embedded systems rarely care about the current time, never mind
>>>> the year. Those that do, but are limited enough to not have support for
>>>> 64-bit types, will not use time_t or any other standard C time or date
>>>> functions - they'll handle it "manually".
>>>>
>>> My sister's oven contains a clock. As does my central heating controller.
>>> Admittedly that's only two out of many microprocessors, some of which
>>> we are doubtless unaware of even owning. But it's enough for Y2038 to
>>> be a potential nuisance.
>>
>> And how many years do you cook for at a time? Ovens generally do not
>> bother much about the real time (and even less about the date). Central
>> heating systems know the time of day, but rarely bother much about the
>> date - certainly not the year.
>
> I agree with your general point, but not what you say about ovens and
> heating systems. My oven knows the real time (I can set it to come on
> automatically) and my heating controller knows the date (I can set a
> "holiday" so that it only keeps the chill off during specified dates).
> I don't think these are rare features these days.
>

That is true - but you are probably no longer in the realms of such
small embedded systems that 64-bit types are not supported by the tools.

If you open a modern heating controller, you might find an embedded
Linux system that talks to a server so that you can control it from an
app on your telephone.

At the very least, you'll find a 32-bit processor supported by modern
gcc and other toolchains with full support for 64-bit types. It may or
may not use time_t and standard C functions for tracking times. It may
or may not have Y38 bugs. But it will be in a different category of
device from those that could not conveniently support a 64-bit time_t.

Am 01.03.2022 um 14:19 schrieb Malcolm McLean:
> On Tuesday, 1 March 2022 at 10:47:37 UTC, David Brown wrote:
>>
>> Small embedded systems rarely care about the current time, never mind
>> the year. Those that do, but are limited enough to not have support for
>> 64-bit types, will not use time_t or any other standard C time or date
>> functions - they'll handle it "manually".
>>
> My sister's oven contains a clock. As does my central heating controller.
> Admittedly that's only two out of many microprocessors, some of which
> we are doubtless unaware of even owning. But it's enough for Y2038 to
> be a potential nuisance.

The oven will stop working a long time before 2038.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Tuesday, 1 March 2022 at 13:33:41 UTC, Dan Purgert wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>> Malcolm McLean wrote:
>> > On Tuesday, 1 March 2022 at 10:47:37 UTC, David Brown wrote:
>> >>
>> >> Small embedded systems rarely care about the current time, never mind
>> >> the year. Those that do, but are limited enough to not have support for
>> >> 64-bit types, will not use time_t or any other standard C time or date
>> >> functions - they'll handle it "manually".
>> >>
>> > My sister's oven contains a clock. As does my central heating controller.
>> > Admittedly that's only two out of many microprocessors, some of which
>> > we are doubtless unaware of even owning. But it's enough for Y2038 to
>> > be a potential nuisance.
>> Does the clock happen to count the year and/or reference the UNIX Epoch
>> at all? My microwave / oven don't...
>>
> I don't have access to the code. But it will have a function called something like
> query_clock(), That might return hour /minute /second, with caller responsible
> for wrapping at midnight. Or it might return a "time in seconds since an arbitrary
> date", in which case caller doens't need to bother about wrapping, until the
> width of the return value overflow.

My microwave oven has a clock display. It provides a way to set the
time, but no way to set the date. *Maybe* it uses time_t internally,
but since the clock resets to 00:00 when it loses power, there's no way
for it to know what the current year is. More likely it only stores the
current time of day and has no concept of the date. Note that I have to
change the time manually on DST transitions.

--
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 */

trimmed followups to comp.lang.c

In comp.lang.c Siri Cruise <chine.bleu@yahoo.com> wrote:
> In article <svjioa$afj$1@dont-email.me>,
<snip>

> What is the Y2K38 problem? That programmers think Y2K38 is more
> efficient than Year 2038.

That is the press, saying 2038 is not "1337" :)

--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

On 3/1/2022 11:31 AM, David Brown wrote:
> On 01/03/2022 08:10, Siri Cruise wrote:
>> In article <874k4inu4v.fsf@nosuchdomain.example.com>,
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>>> There are probably non-conforming small embedded
>>> implementations that don't.
>>
>> Maybe it's time to offer a bounty, dead or alive, for them. The
>> really crappy parts of C are excused 'but we have to include
>> small embedded system'. Rest of the world is paying a subsidy
>> because some system integrators use cheap crippled chips.
>> Apparently C is not allowed to assume floating point arithmetic:
>> C has to assume it is running on 1970 era hardware.
>>
>

[...]

>
>
> Oh, and these "small embedded systems" that you dislike so much are what
> make the world go round. It's not 1970 era

Not at all, nowadays there are many orders of magnitude more tiny
processors running out there than in the '70s - not even comparable.

- a tiny fraction of a
> percent of the processors made /today/ have hardware floating point
> support. But you can use floating point in your C programming quite
> happily - that's the whole point of using high-level languages like C
> instead of assembly.
>

And, how many of these tiny embedded systems do have a need for a
universal clock?

On 3/1/2022 1:05 PM, Bonita Montero wrote:
> Am 01.03.2022 um 14:19 schrieb Malcolm McLean:
>> On Tuesday, 1 March 2022 at 10:47:37 UTC, David Brown wrote:
>>>
>>> Small embedded systems rarely care about the current time, never mind
>>> the year. Those that do, but are limited enough to not have support for
>>> 64-bit types, will not use time_t or any other standard C time or date
>>> functions - they'll handle it "manually".
>>>
>> My sister's oven contains a clock. As does my central heating controller.
>> Admittedly that's only two out of many microprocessors, some of which
>> we are doubtless unaware of even owning. But it's enough for Y2038 to
>> be  a potential nuisance.
>
> The oven will stop working a long time before 2038.

That is only 16 years away. My oven was installed in 1998, 24 years ago.

Lynn

On 01/03/2022 20:29, Manfred wrote:
> On 3/1/2022 11:31 AM, David Brown wrote:
>> On 01/03/2022 08:10, Siri Cruise wrote:
>>> In article <874k4inu4v.fsf@nosuchdomain.example.com>,
>>>   Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>
>>>> There are probably non-conforming small embedded
>>>> implementations that don't.
>>>
>>> Maybe it's time to offer a bounty, dead or alive, for them. The
>>> really crappy parts of C are excused 'but we have to include
>>> small embedded system'. Rest of the world is paying a subsidy
>>> because some system integrators use cheap crippled chips.
>>> Apparently C is not allowed to assume floating point arithmetic:
>>> C has to assume it is running on 1970 era hardware.
>>>
>>
>
> [...]
>
>>
>>
>> Oh, and these "small embedded systems" that you dislike so much are what
>> make the world go round.  It's not 1970 era
>
> Not at all, nowadays there are many orders of magnitude more tiny
> processors running out there than in the '70s - not even comparable.
>
>  - a tiny fraction of a
>> percent of the processors made /today/ have hardware floating point
>> support.  But you can use floating point in your C programming quite
>> happily - that's the whole point of using high-level languages like C
>> instead of assembly.
>>
>
> And, how many of these tiny embedded systems do have a need for a
> universal clock?

Almost none - that was my point.

In article <svksmc$j3p$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:

> Oh, and these "small embedded systems" that you dislike so much are what
> make the world go round. It's not 1970 era - a tiny fraction of a

I don't dislike them. For C standards, library standards, etc
caterring to their cheapness costs everyone else. Rest of the C
world ends up subsidising them.

You are allowed to use horse drawn carriages for travel. But not
on interstate highways. Making interstates compatiable with
horses would make interstates more expensive with cars and trucks
paying for horse access they will never use. Even on rural roads
carriages have some restrictions imposed such as buying
reflectors to make them more visible.

> percent of the processors made /today/ have hardware floating point
> support. But you can use floating point in your C programming quite
> happily - that's the whole point of using high-level languages like C
> instead of assembly.

Since I'm working on a crippled mac, I can't look up examples,
but some of the real stupidities of C are excused as 'what about
embedded system'. Did you know that messages can be transmitted
on AC power distribution; low bandwidth, but possible. Look at
the excuses for clock nonsense above. So why not send current
time through AC power? Then every system on AC power can have
current time with microseconds. 'No! we can't do that because of
the huge installed base of embedded systems. The required
hardware might be $0.0000001. Over millions of units that $1 !!!
how dare we finaly solve a universal problem that costs embedded
systems money!

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

On 02/03/2022 16:20, Siri Cruise wrote:
> In article <svksmc$j3p$1@dont-email.me>,
> David Brown <david.brown@hesbynett.no> wrote:
>
>> Oh, and these "small embedded systems" that you dislike so much are what
>> make the world go round. It's not 1970 era - a tiny fraction of a
>
> I don't dislike them. For C standards, library standards, etc
> caterring to their cheapness costs everyone else. Rest of the C
> world ends up subsidising them.
>
> You are allowed to use horse drawn carriages for travel. But not
> on interstate highways. Making interstates compatiable with
> horses would make interstates more expensive with cars and trucks
> paying for horse access they will never use. Even on rural roads
> carriages have some restrictions imposed such as buying
> reflectors to make them more visible.

A better analogy would be walking compared to flying. Yes, walking is
slower and you can't carry as much, as far, and as fast as with a plane.
But it's everywhere.

Seriously, you need to get over your misunderstandings here. There is
no "subsidising" here by "the rest of the C world". If you were to look
at numbers of processors, small-systems embedded C /is/ the C world.
Everything else is minor in comparison. Of course, I don't think simple
counts of processor numbers is a particularly good way of judging
importance.

Let's try a different viewpoint. In small-systems embedded programming,
the solid majority program in C. Some use C++, generally in a somewhat
limited fashion - and I think its reasonable to suggest that people
should be using more C++ in this kind of system. There is also a small
amount of assembly, Ada, Forth, and other languages. In "big systems"
programming, only a very small fraction of programmers use C. And most
of them should be using something else. C has a critical part to play
in the foundations of any big system - the OS, the key libraries, the
virtual machines that other languages run on.

>
>> percent of the processors made /today/ have hardware floating point
>> support. But you can use floating point in your C programming quite
>> happily - that's the whole point of using high-level languages like C
>> instead of assembly.
>
> Since I'm working on a crippled mac, I can't look up examples,
> but some of the real stupidities of C are excused as 'what about
> embedded system'.

I'd like to see some of these examples.

> Did you know that messages can be transmitted
> on AC power distribution; low bandwidth, but possible.

They can also be distributed by carrier pigeons. (There's even an RFC,
and it was implemented by some students.) So what?

> Look at
> the excuses for clock nonsense above. So why not send current
> time through AC power? Then every system on AC power can have
> current time with microseconds. 'No! we can't do that because of
> the huge installed base of embedded systems. The required
> hardware might be $0.0000001. Over millions of units that $1 !!!
> how dare we finaly solve a universal problem that costs embedded
> systems money!
>

You are just making stuff up, without the slightest idea what you are
talking about here. Sorry, but you are wrong on so many counts here
that it is not worth trying to correct you - it should be obvious to anyone.

On 2022-03-01, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 2/28/22 8:38 PM, Siri Cruise wrote:
>>> In article <svjioa$afj$1@dont-email.me>,
>>> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>>
>>>> I suspect that as we get closer to 2038, we will find more and more
>>>> software subject to the year 2038 problem.
>>> What is the Y2K38 problem? That programmers think Y2K38 is more
>>> efficient than Year 2038.
>>>
>>
>> https://en.wikipedia.org/wiki/Year_2038_problem
>>
>> On January 19, 2038 at 3:14:07 UTC, the signed 32 bit Unix timestamp
>> overflows, and will think it is 1901.
>
> I think most OSes have been fixed to use a wider type, have they not?
> The more worrying problem is programs that store the timestamp in 32
> bits.

Not exactly. 64 bit operating systems have 64 bit time_t.

There are still 32 bit systms out there. 32 bit systems can have a 64
bit time_t also; this is similar to large file support with a 64 bit
off_t.

Notably, the GNU C Library ("glibc") has just recently, like in the past
year, introduced a macro for selecting a big time_t, which individual
applications or distro builds have to use.

(I added a configure test for this into TXR about a month ago; but
couldn't find a distro with a sufficiently new glibc to even test it.
If -D_TIME_BITS=64 changes the size of time_t, then that flag is
included in the build. It is risky, because obviously there may be
interoperability problems; like what if you make a FFI call using
some structure that contains time_t fields, to a library which was
built without this option?

It's a really poor solution, because time is not like file sizes.
It's possible to declare that an application is only concerned with
small files, but close to and beyond Y2038 it is not possible to
reasonably declare that a program which deals with time only has to be
concerned with "small time".

I think other libc's just went to large time and that's it; any
glibc distro for 32 bits will have to hard code the 64 bit time_t,
or at least propagate the macro through the entire distro build and
bake it into the toolchain.

> On early 16-bit systems, the
> timestamp could not be returned as there was no 32-bit integer type.
> The spec was
>
> time(tvec)
> int tvec[2];

Also, I seem to remember that early struct returning was not necessarily
re-entrant.

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

On 2022-03-01, Siri Cruise <chine.bleu@yahoo.com> wrote:
> In article <874k4inu4v.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> There are probably non-conforming small embedded
>> implementations that don't.
>
> Maybe it's time to offer a bounty, dead or alive, for them. The

No develpment bounty will repair the *installations* of these embedded
systems that cannot be upgraded with new firmware for whatever reason.

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

On 02/03/2022 17:28, David Brown wrote:
> On 02/03/2022 16:20, Siri Cruise wrote:

>
>> Did you know that messages can be transmitted
>> on AC power distribution; low bandwidth, but possible.
>
> They can also be distributed by carrier pigeons. (There's even an RFC,
> and it was implemented by some students.) So what?
>
>> Look at
>> the excuses for clock nonsense above. So why not send current
>> time through AC power? Then every system on AC power can have
>> current time with microseconds. 'No! we can't do that because of
>> the huge installed base of embedded systems. The required
>> hardware might be $0.0000001. Over millions of units that $1 !!!
>> how dare we finaly solve a universal problem that costs embedded
>> systems money!
>>
>
> You are just making stuff up, without the slightest idea what you are
> talking about here. Sorry, but you are wrong on so many counts here
> that it is not worth trying to correct you - it should be obvious to anyone.
>

Let me just ask one question here. /Who/ should send the current time
through AC power, in your opinion?

On Wednesday, 2 March 2022 at 21:36:24 UTC+2, David Brown wrote:
> On 02/03/2022 17:28, David Brown wrote:
> > On 02/03/2022 16:20, Siri Cruise wrote:
>
> >
> >> Did you know that messages can be transmitted
> >> on AC power distribution; low bandwidth, but possible.
> >
> > They can also be distributed by carrier pigeons. (There's even an RFC,
> > and it was implemented by some students.) So what?
> >
> >> Look at
> >> the excuses for clock nonsense above. So why not send current
> >> time through AC power? Then every system on AC power can have
> >> current time with microseconds. 'No! we can't do that because of
> >> the huge installed base of embedded systems. The required
> >> hardware might be $0.0000001. Over millions of units that $1 !!!
> >> how dare we finaly solve a universal problem that costs embedded
> >> systems money!
> >>
> >
> > You are just making stuff up, without the slightest idea what you are
> > talking about here. Sorry, but you are wrong on so many counts here
> > that it is not worth trying to correct you - it should be obvious to anyone.
> >
> Let me just ask one question here. /Who/ should send the current time
> through AC power, in your opinion?

Have you noticed that someone sells us AC power? Must be hard to not
notice given the recent fuck-ups in Europe. Those may be easily made
obliged to as they can't somehow run away.

Öö Tiib <ootiib@hot.ee> writes:
> On Wednesday, 2 March 2022 at 21:36:24 UTC+2, David Brown wrote:
>> On 02/03/2022 17:28, David Brown wrote:
>> > On 02/03/2022 16:20, Siri Cruise wrote:
>> >> Did you know that messages can be transmitted
>> >> on AC power distribution; low bandwidth, but possible.
>> >
>> > They can also be distributed by carrier pigeons. (There's even an RFC,
>> > and it was implemented by some students.) So what?
>> >
>> >> Look at
>> >> the excuses for clock nonsense above. So why not send current
>> >> time through AC power? Then every system on AC power can have
>> >> current time with microseconds. 'No! we can't do that because of
>> >> the huge installed base of embedded systems. The required
>> >> hardware might be $0.0000001. Over millions of units that $1 !!!
>> >> how dare we finaly solve a universal problem that costs embedded
>> >> systems money!
>> >
>> > You are just making stuff up, without the slightest idea what you are
>> > talking about here. Sorry, but you are wrong on so many counts here
>> > that it is not worth trying to correct you - it should be obvious to anyone.
>> >
>> Let me just ask one question here. /Who/ should send the current time
>> through AC power, in your opinion?
>
> Have you noticed that someone sells us AC power? Must be hard to not
> notice given the recent fuck-ups in Europe. Those may be easily made
> obliged to as they can't somehow run away.

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.) And you expect this new time
signal to be used by millions of devices at a cost of $0.0000001 per
device.

Of course it would be useless for mobile devices.

What exactly does this have to do with C (which doesn't even require
freestanding implementations to support <time.h>)?

--
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 Thursday, 3 March 2022 at 02:19:01 UTC+2, Keith Thompson wrote:
> Öö Tiib <oot...@hot.ee> writes:
> > On Wednesday, 2 March 2022 at 21:36:24 UTC+2, David Brown wrote:
> >> On 02/03/2022 17:28, David Brown wrote:
> >> > On 02/03/2022 16:20, Siri Cruise wrote:
> >> >> Did you know that messages can be transmitted
> >> >> on AC power distribution; low bandwidth, but possible.
> >> >
> >> > They can also be distributed by carrier pigeons. (There's even an RFC,
> >> > and it was implemented by some students.) So what?
> >> >
> >> >> Look at
> >> >> the excuses for clock nonsense above. So why not send current
> >> >> time through AC power? Then every system on AC power can have
> >> >> current time with microseconds. 'No! we can't do that because of
> >> >> the huge installed base of embedded systems. The required
> >> >> hardware might be $0.0000001. Over millions of units that $1 !!!
> >> >> how dare we finaly solve a universal problem that costs embedded
> >> >> systems money!
> >> >
> >> > You are just making stuff up, without the slightest idea what you are
> >> > talking about here. Sorry, but you are wrong on so many counts here
> >> > that it is not worth trying to correct you - it should be obvious to anyone.
> >> >
> >> Let me just ask one question here. /Who/ should send the current time
> >> through AC power, in your opinion?
> >
> > Have you noticed that someone sells us AC power? Must be hard to not
> > notice given the recent fuck-ups in Europe. Those may be easily made
> > obliged to as they can't somehow run away.
>
> 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.) And you expect this new time
> signal to be used by millions of devices at a cost of $0.0000001 per
> device.

I'm relatively uninterested in time information over AC. It is bit
annoying that clock on microwave oven is always slightly wrong
.... and that is it. The price said was certain nonsense.
> Of course it would be useless for mobile devices.

On any devices with at least myriameter band radio capability as
these can use other sources.

> What exactly does this have to do with C (which doesn't even require
> freestanding implementations to support <time.h>)?

That I've been also annoyed about. Nonsense calendars of RTC
chips are sometimes ridiculous as are often the replacements
that one or other team wrote to <time.h>.

On 03/03/2022 01:18, Keith Thompson wrote:
> Öö Tiib <ootiib@hot.ee> writes:
>> On Wednesday, 2 March 2022 at 21:36:24 UTC+2, David Brown wrote:
>>> On 02/03/2022 17:28, David Brown wrote:
>>>> On 02/03/2022 16:20, Siri Cruise wrote:
>>>>> Did you know that messages can be transmitted
>>>>> on AC power distribution; low bandwidth, but possible.
>>>>
>>>> They can also be distributed by carrier pigeons. (There's even an RFC,
>>>> and it was implemented by some students.) So what?
>>>>
>>>>> Look at
>>>>> the excuses for clock nonsense above. So why not send current
>>>>> time through AC power? Then every system on AC power can have
>>>>> current time with microseconds. 'No! we can't do that because of
>>>>> the huge installed base of embedded systems. The required
>>>>> hardware might be $0.0000001. Over millions of units that $1 !!!
>>>>> how dare we finaly solve a universal problem that costs embedded
>>>>> systems money!
>>>>
>>>> You are just making stuff up, without the slightest idea what you are
>>>> talking about here. Sorry, but you are wrong on so many counts here
>>>> that it is not worth trying to correct you - it should be obvious to anyone.
>>>>
>>> Let me just ask one question here. /Who/ should send the current time
>>> through AC power, in your opinion?
>>
>> Have you noticed that someone sells us AC power? Must be hard to not
>> notice given the recent fuck-ups in Europe. Those may be easily made
>> obliged to as they can't somehow run away.
>
> 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.

> And you expect this new time
> signal to be used by millions of devices at a cost of $0.0000001 per
> device.
>
> Of course it would be useless for mobile devices.
>
> What exactly does this have to do with C (which doesn't even require
> freestanding implementations to support <time.h>)?
>

I'm sure Siri can explain to us how the C standards could be so much
better after they are freed from the constraints and limitations they
contain to pander to small embedded systems, and how all that will
change once electricity providers are forced to send time signals and
every embedded system has its 1 µ$ decoder added.

No, it doesn't have much to do with C, and even less connection with
reality. Hopefully it was just a one-off from someone posting a crazy
idea without thinking, and now it can be dropped. I /could/ give some
of the reasons why it would be impossible, regardless of the price, but
that would be of little interest to most people, and certainly
off-topic. I suggest that if anyone really wants to take it further,
they start a new thread in comp.arch.embedded.

David Brown <david.brown@hesbynett.no> writes:
>On 03/03/2022 01:18, Keith Thompson wrote:
>> Öö Tiib <ootiib@hot.ee> writes:
>>> On Wednesday, 2 March 2022 at 21:36:24 UTC+2, David Brown wrote:
>>>> On 02/03/2022 17:28, David Brown wrote:
>>>>> On 02/03/2022 16:20, Siri Cruise wrote:
>>>>>> Did you know that messages can be transmitted
>>>>>> on AC power distribution; low bandwidth, but possible.
>>>>>
>>>>> They can also be distributed by carrier pigeons. (There's even an RFC,
>>>>> and it was implemented by some students.) So what?
>>>>>
>>>>>> Look at
>>>>>> the excuses for clock nonsense above. So why not send current
>>>>>> time through AC power? Then every system on AC power can have
>>>>>> current time with microseconds. 'No! we can't do that because of
>>>>>> the huge installed base of embedded systems. The required
>>>>>> hardware might be $0.0000001. Over millions of units that $1 !!!
>>>>>> how dare we finaly solve a universal problem that costs embedded
>>>>>> systems money!
>>>>>
>>>>> You are just making stuff up, without the slightest idea what you are
>>>>> talking about here. Sorry, but you are wrong on so many counts here
>>>>> that it is not worth trying to correct you - it should be obvious to anyone.
>>>>>
>>>> Let me just ask one question here. /Who/ should send the current time
>>>> through AC power, in your opinion?
>>>
>>> Have you noticed that someone sells us AC power? Must be hard to not
>>> notice given the recent fuck-ups in Europe. Those may be easily made
>>> obliged to as they can't somehow run away.
>>
>> 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.

Most of the RF will get filtered out by the distribution transformers
anyway.

On 28/02/2022 22:35, Lynn McGuire 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."
>
> I suspect that as we get closer to 2038, we will find more and more
> software subject to the year 2038 problem.
>    https://en.wikipedia.org/wiki/Year_2038_problem
>
I'm not going to go all the way through the thread, sorry. But...

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.

Andy

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

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.

On 3/4/2022 12:42 AM, 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."

lol