"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

Lynn

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.

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

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.

There may be systems that don't have a wider native type, but that
should not be insurmountable. After all, that was the case in early
Unix. That's why time(2) takes a pointer. 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];

--
Ben.

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,

Yes.

> and will think it is 1901.

Maybe. It depends on how the time() function is implemented. Some
implementations might return (time_t)(-1) if the calendar time is not
available; that's likely to be interpreted as 1969-12-31 23:59:59 UTC.

(Signed arithmetic overflow has undefined behavior, but that shouldn't
affect the time() function, which is required to return either "the
implementation’s best approximation to the current calendar time" or
(time_t)(-1).)

Of course some time() function implementations might be buggy.

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

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Richard Damon <Richard@Damon-Family.org> writes:
[...]
>>> 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.
[...]
>>
>> 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.

There are plenty of embedded systems that still use 32-bit time_t, and
some of them are going to be difficult to upgrade.

Even on my 64-bit Ubuntu system, "gcc -m32" uses a 32-bit time_t.

> There may be systems that don't have a wider native type, but that
> should not be insurmountable. After all, that was the case in early
> Unix. That's why time(2) takes a pointer. 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];

All conforming C implementations since C99 support at least 64-bit
integers. There are probably non-conforming small embedded
implementations that don't. Dealing with Y2038 for such system is left
as an exercise.

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

In comp.lang.c++ Richard Damon <Richard@damon-family.org> wrote:
> 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.

Why would it think it's 1901 given that Unix time starts at 1 Jan 1970?

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.

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

["Followup-To:" header set to comp.lang.c.]
Juha Nieminen wrote:
> In comp.lang.c++ Richard Damon <Richard@damon-family.org> wrote:
>> 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.
>
> Why would it think it's 1901 given that Unix time starts at 1 Jan 1970?

Because time_t is signed.

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

Standard C has float and double types (and long double, but that doesn't
have to be bigger than double). C does not care about the hardware - it
defines the language and the functionality, not the efficiency. So you
have floating point regardless of the hardware.

So any implementation of standard C has support for 32-bit float and
64-bit double. (Technically the sizes could be different, but I've
never seen that in practice.) Some small implementations might be only
partially conforming, and have 32-bit double, and perhaps no "long long
int", but those are not standard.

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

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

["Followup-To:" header set to comp.lang.c++.]
Juha Nieminen wrote:
> In comp.lang.c++ Richard Damon <Richard@damon-family.org> wrote:
>> 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.
>
> Why would it think it's 1901 given that Unix time starts at 1 Jan 1970?

"time" is (well, at least the affected implementation is) a signed
32-bit integer.

"0" (0b0000 [...] 0000) corresponds to 1970-01-01 00:00:00 UTC.
However, when we reach the signed 32-bit maximum value (2,147,483,647 --
0b0111 [...] 1111), the next second will wrap to the minimum
(-2,147,483,648 -- 0b1000 [...] 0000), subtracting 68 years, 18 days
from 1970-01-01 (so, 1901-12-13).

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

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmId9vgACgkQbWVw5Uzn
KGCDuA//XvZNX+J0XHEp2SKM8i3KGco/MmE46eLq0FaK/FdfGyF6OK6dVN70ot+l
rVPPVUuu61nJxx5zJJNiMRoVXQciwqLKPqm2c8Uc/euJ+LDrjm0+XUUPbjXhjoKg
OcqT+86fkHiM7MzmJCNoveb09GChCkKuj6xYAP7RzOBLCNudk/D+S/A26rjpqwFi
NN/nP9mAtvYLvfGJbllZj957QELo+4fxGcZh1vyUxi7T4sVYjXmPynP788lyiHTV
jubNU1xu18sXddiCaj7occfRFZ634i+dCGJXjd2S0ODAzyGduO6AGlR9ev14zypW
D8k8eOwujn4wl+RtZq+VOcc99Je6iUt6t6rv1MVZKVTQzJhkpchALAjIfUOBy8Ln
50VEwiKYjl+w3nC83kz9hdN0K03cIKWHStGca2KB78+qJi0SeQFjxmIJPMblNBay
tJVEO9k4+uvQ2LKz3LVtIEUaV4MjrZnSMetXNWKQs4I3NJFXk1xD5LkQ0iqKFU7w
Mfv8EiIZfe0NDz5jRZI/YfSXJVFtYaq1Eoz6Sq2lCmQyusWcqiE0JKjpBBHKvLud
fMemG/PSeg/qr7fMmBKc285+gpLhlKMVEDdsEcl+Kv0yc0cAxUUpEQLpsUWBhOyW
7e7QqwUe1E0Ey4KiwwaPxo3Q/GkJlkvj/CDwoA0AzWIkgR4L9Dk=
=G24+
-----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 01/03/2022 06:01, Keith Thompson wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

>> There may be systems that don't have a wider native type, but that
>> should not be insurmountable. After all, that was the case in early
>> Unix. That's why time(2) takes a pointer. 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];
>
> All conforming C implementations since C99 support at least 64-bit
> integers. There are probably non-conforming small embedded
> implementations that don't. Dealing with Y2038 for such system is left
> as an exercise.
>

It is almost entirely a non-issue for such systems. ("Almost" is,
however, important here.)

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

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.

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

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

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIeIMQACgkQbWVw5Uzn
KGC3BBAAleXXq2+qZ9tBpQXsPWZ+MGjRngEl3YgzfYcaa6UYMTn4WiNez6zX/2HX
DMi9nHpyho3e8hvd3zddw1UK19+QnAoblocNIj0OYLxEyKsyTbE0E8eC57CSC9zs
uXBnFI00Ag54LHryK4bYJ9S3J+I+ecvY67FWe4syjEfnJ/NEH047VuxJ93XAthwm
rfOIe25VQ4XTtPfYHwk9DrmW/1t63wsIIJ88UsUJ1h1JhFQzlGjsIqsv2gE3mQHM
p9iidTvAvp2XH7Jktt+iJFSCb3MmNrVNau+GagnP97hIY2gYOugQR8eIdFqmIKZR
Ddiy3lTwgi/KLdvN3dfVhG8EtBzI3iGCt3MMDFdLCIAnvh3nAGT5LKErUXxEcmfD
JxklNGFtj6lxj7VicVDIFu0GUlTiayKERutu66hCSelRjCfoNxEOP+cP6k2VXqLL
njwzGp3ZgO7jEi1ZWR1mZmSwNtl20a3sxvU+VA9JNZ9+TuenWhXXgKqY8NpN8MgA
Q6Ss5yfmVY9FZl2qDf7TmvUxOuFfx2RKavbIHpmwguqPIFP1204mkWpKhJYVMk54
XFpTjEFeAyo14M5P+mvAEJEc8Mib2n3K6tvM88/4bo9OTYRUVSbxHOJAsytllVnr
akubHGQ0nQpNWu8zj+ImihYzgcSIYts2A8njlNFdqYkQt8pzJ5o=
=lwDm
-----END PGP SIGNATURE-----

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

Am 01.03.2022 um 11:12 schrieb Robert Latest:
> ["Followup-To:" header set to comp.lang.c.]
> Juha Nieminen wrote:
>> In comp.lang.c++ Richard Damon <Richard@damon-family.org> wrote:
>>> 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.
>>
>> Why would it think it's 1901 given that Unix time starts at 1 Jan 1970?
>
> Because time_t is signed.

Even Windows' FILETIME is unsigned Windows doesn't allow
FILETIMEs with the high bit set.

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.

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.

Sure, there are /some/ small systems that need to track the year. But
my point is that the overlap between systems that are so small and
limited that the C implementations don't support 64-bit types, and
systems that need to track the year correctly, is tiny. And even in
that overlap, Y38 will not be a problem for most because they are
unlikely to be using time_t.

Of course there will be systems that use time_t and fail to handle year
2038 correctly - there are always systems with faults and limitations.
However, very small systems with limited C implementations are not the
prime suspect for Y38 problems.

Am 01.03.2022 um 15:35 schrieb Bonita Montero:
> Am 01.03.2022 um 11:12 schrieb Robert Latest:
>> ["Followup-To:" header set to comp.lang.c.]
>> Juha Nieminen wrote:
>>> In comp.lang.c++ Richard Damon <Richard@damon-family.org> wrote:
>>>> 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.
>>>
>>> Why would it think it's 1901 given that Unix time starts at 1 Jan 1970?
>>
>> Because time_t is signed.
>
> Even Windows' FILETIME is unsigned Windows doesn't allow
> FILETIMEs with the high bit set.

Here's a nice C++-class I've written that resembles Win32
SYSTEM_TIME and has a conversion to / from 64 bit FILETIMEs.

#pragma once
#include <cstdint>
#include <compare>

struct t_system_time
{ std::uint16_t year;
std::uint8_t weekDay, month, day;
std::uint8_t hour, minute, second;
std::uint32_t ns100;
std::strong_ordering operator <=>( t_system_time const &other ) const =
default;
bool operator ==( t_system_time const &other ) const = default;
};

struct system_time : public t_system_time
{ system_time() {}
system_time( system_time const & ) = default;
system_time( std::uint16_t year, std::uint8_t weekDay, std::uint8_t
month, std::uint8_t day, std::uint8_t hour, std::uint8_t minute,
std::uint8_t second, std::uint32_t ns100 );
system_time( std::uint64_t timeStamp );
operator std::uint64_t();
system_time &operator =( std::uint64_t timeStamp );
system_time &operator =( system_time const & ) = default;
private:
void assign( std::uint64_t timeStamp );
static uint64_t const
MILLISECOND = 10'000,
SECOND = 1'000 * MILLISECOND,
MINUTE = 60 * SECOND,
HOUR = 60 * MINUTE,
DAY = 24 * HOUR,
WEEK = 7 * DAY,
NON_LEAP_YEAR = 365 * DAY,
LEAP_YEAR = 366 * DAY,
FOUR_YEARS_W_LJ = LEAP_YEAR + 3 * NON_LEAP_YEAR,
FOUR_YEARS_WO_LJ = 4 * NON_LEAP_YEAR,
FIRST_QUARTER_CENTURY = 25 * FOUR_YEARS_W_LJ,
REMAINING_QUARTER_CENUTRIES = 25 * FOUR_YEARS_W_LJ - DAY,
FOUR_HUNDRED_YEARS = FIRST_QUARTER_CENTURY + 3 *
REMAINING_QUARTER_CENUTRIES;
};

inline
system_time::system_time( std::uint16_t year, std::uint8_t weekDay,
std::uint8_t month, std::uint8_t day, std::uint8_t hour, std::uint8_t
minute, std::uint8_t second, std::uint32_t ns100 )
{ this->year = year;
this->weekDay = weekDay;
this->month = month;
this->day = day;
this->hour = hour;
this->minute = minute;
this->second = second;
this->ns100 = ns100;
}

inline
system_time::system_time( std::uint64_t timeStamp )
{ assign( timeStamp );
}

inline
system_time &system_time::operator =( std::uint64_t timeStamp )
{ assign( timeStamp );
}

#include <stdexcept>
#include <cassert>
#if defined(__cpp_lib_hardware_interference_size)
#include <new>
#endif
#include "system_time.h"

using namespace std;

#if defined(__cpp_lib_hardware_interference_size)
#define CL_SIZE std::hardware_destructive_interference_size
#else
#define CL_SIZE 64
#endif

//#define BINARY_SEARCH

void system_time::assign( uint64_t timeStamp )
{ if( timeStamp > 0x7FFF35F4F06C7FFFu ) // > 31.12.30827 23:59.9999999
throw invalid_argument( "toSystemTime() - invalid timestamp" );
timeStamp += LEAP_YEAR; // 1601 - 1600 = non leap year
weekDay = ((timeStamp - timeStamp / WEEK * WEEK) / DAY + 6) % 7;
uint64_t tsCalc = timeStamp;
uint16_t y400, y100, y4, y;
y400 = (uint16_t)(tsCalc / FOUR_HUNDRED_YEARS);
tsCalc -= y400 * FOUR_HUNDRED_YEARS;
bool leapYear;
auto leapQuad = [&]()
{
if( tsCalc >= LEAP_YEAR ) [[likely]]
// y >= 1
y = (uint16_t)(1 + (tsCalc - LEAP_YEAR) / NON_LEAP_YEAR), // 1 ... 3
tsCalc -= LEAP_YEAR + (tsCalc - LEAP_YEAR) / NON_LEAP_YEAR *
NON_LEAP_YEAR,
leapYear = false;
else
// y == 0
y = 0,
leapYear = true;
};
if( tsCalc >= FIRST_QUARTER_CENTURY ) [[likely]]
{
// (y % 400) >= 100
y100 = (uint16_t)(1 + (tsCalc - FIRST_QUARTER_CENTURY) /
REMAINING_QUARTER_CENUTRIES); // 1 ... 3
tsCalc -= FIRST_QUARTER_CENTURY + (tsCalc - FIRST_QUARTER_CENTURY) /
REMAINING_QUARTER_CENUTRIES * REMAINING_QUARTER_CENUTRIES;
if( tsCalc >= FOUR_YEARS_WO_LJ ) [[likely]]
{
// (y % 400) >= 100 && (y % 4) >= 4
y4 = (uint16_t)(1 + (tsCalc - FOUR_YEARS_WO_LJ) / FOUR_YEARS_W_LJ);
// 1 ... 24
tsCalc -= FOUR_YEARS_WO_LJ + (tsCalc - FOUR_YEARS_WO_LJ) /
FOUR_YEARS_W_LJ * FOUR_YEARS_W_LJ;
leapQuad();
}
else
// (y % 400) >= 100 && (y % 4) < 4
y4 = 0,
y = (uint16_t)(tsCalc / NON_LEAP_YEAR),
tsCalc -= tsCalc / NON_LEAP_YEAR * NON_LEAP_YEAR,
leapYear = false;
}
else
// (y % 400) < 100
y100 = 0,
y4 = (uint16_t)(tsCalc / FOUR_YEARS_W_LJ),
tsCalc -= tsCalc / FOUR_YEARS_W_LJ * FOUR_YEARS_W_LJ,
leapQuad();
year = 1600 + 400 * y400 + 100 * y100 + 4 * y4 + y;
{
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];
#if defined(BINARY_SEARCH)
size_t lower = 0, upper = 12, hit = -1, mid;
do
{
mid = (lower + upper) / 2;
if( pMonthOffsets[mid] <= tsCalc )
hit = mid,
lower = mid + 1;
else
upper = mid;
} while( lower != upper );
#else
size_t hit;
for( hit = 0; tsCalc >= pMonthOffsets[hit + 1]; ++hit );
#endif
assert(hit != -1);
uint8_t dy = (uint8_t)((tsCalc - pMonthOffsets[hit]) / DAY);
tsCalc -= pMonthOffsets[hit] + dy * DAY;
month = 1 + (uint8_t)hit;
day = 1 + dy;
}
hour = (uint8_t)(tsCalc / HOUR);
tsCalc %= HOUR;
minute = (uint8_t)(tsCalc / MINUTE);
tsCalc %= MINUTE;
second = (uint8_t)(tsCalc / SECOND);
tsCalc %= SECOND;
ns100 = (uint32_t)tsCalc;
}

system_time::operator uint64_t()
{ if( year < 1601 || year > 30827 ) [[unlikely]]
throw invalid_argument( "fromSystemTime() - year out of range" );
if( month < 1 || month > 12 ) [[unlikely]]
throw invalid_argument( "fromSystemTime() - month out of range" );
bool isLeapYear = year % 4 == 0 && year % 100 != 0 || year % 400 == 0;
static
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 }
};
if( day == 0 || day > montLengths[isLeapYear][month] ) [[unlikely]]
throw invalid_argument( "fromSystemTime() - day out of range" );
if( hour >= 24 ) [[unlikely]]
throw invalid_argument( "fromSystemTime() - hour out of range" );
if( minute >= 60 ) [[unlikely]]
throw invalid_argument( "fromSystemTime() - minute out of range" );
if( second >= 60 ) [[unlikely]]
throw invalid_argument( "fromSystemTime() - second out of range" );
if( ns100 >= 10'000'000 ) [[unlikely]]
throw invalid_argument( "fromSystemTime() - millisecond out of range" );
uint16_t yr = year - 1600;
uint64_t timeStamp = yr / 400 * FOUR_HUNDRED_YEARS;
yr %= 400;
auto leapQuad = [&]()
{
timeStamp += yr / 4 * FOUR_YEARS_W_LJ;
yr %= 4;
if( yr >= 1 ) [[likely]]
timeStamp += LEAP_YEAR + (yr - 1) * NON_LEAP_YEAR;
};
if( yr >= 100 ) [[likely]]
{
timeStamp += FIRST_QUARTER_CENTURY;
yr -= 100;
timeStamp += yr / 100 * REMAINING_QUARTER_CENUTRIES;
yr %= 100;
if( yr >= 4 ) [[likely]]
timeStamp += FOUR_YEARS_WO_LJ,
yr -= 4,
leapQuad();
else
timeStamp += yr * NON_LEAP_YEAR;
}
else
leapQuad();
timeStamp -= LEAP_YEAR; // - (1.1.1601 - 1.1.1600)
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 }
};
timeStamp += (monthOffsets[isLeapYear][month] + day - 1) * DAY;
timeStamp += hour * HOUR;
timeStamp += minute * MINUTE;
timeStamp += second * SECOND;
timeStamp += ns100;
return timeStamp;
}

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.

--
Ben.

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

Malcolm McLean wrote:
> 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.

Yeah, I guess we can come up with any point / counterpoint as to why
2038 (or equivalent) would or would not be problematic for such devices,
huh?

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

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIeS0EACgkQbWVw5Uzn
KGDgnQ//eOrs1Xp3ieLQbKs/mqI4t2tkdkduda+0l1SPGXDyJ9rhMzs7de89tpbh
rzdgSPR/SZ5KBviTMnuSmmtknGH/IVvQUa2ll2ov77NHmMBfW7wHzcx5SaniVWdZ
JMlBZYC+VSlR6N3cywxtGVFTxb9Mgpzjs7JLkYY3YkxAhY/a6UIcGtRdGy2qchTF
7vQBLrkLXjkh7ZKJyZy4i1TmzioNTLqS0hAxGY1Mv9eKn/wolwkCC+oRnYW4ZwVM
GB42A9TwkRnDl9wlCFY0QZA6lyJx58W0f10aQ1kpi75dSS4zsZ36oEeNCs3up8X5
h+XAVJDIjyYi+kWo3rlflMa6TXaddtPvoqWwEyir9lfdjGm4b1AGBU+fwH9qjF3y
wuljQSqS2yuleKkslawBevIKcWAgFytbmk4N/Sf632yLp81WGtTMZFOTDGhfu4mV
SBLE5zs2vjh4hEWlgVnlnvXgHGjFUe1qarYTUHewNMJQuz2nU7uoahmDnXlREJ64
kJED6yP0/dDUAU/5PH0U8BeXgmG4XAIW5V+YVlZAJMLbO+n5Vf2tDOqN+yQgbe+n
fk2M9ajiNPKygjbW792bcayHsNOiYuxxcTxKi65XQxFM9cM146vNUNtvzFzyRoGd
6UqobXGzpMDKo7AIFlLgQl8d0ijP5Ly5zfOT061pUoehDBDTJTo=
=Vlmb
-----END PGP SIGNATURE-----

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

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.

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.

Bonita Montero <Bonita.Montero@gmail.com> writes:

>Here's a nice C++-class I've written that resembles Win32

<200 lines of grossly verbose (worse than COBOL) C++ elided>

This is comp.lang.c.

Am 01.03.2022 um 17:42 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> Here's a nice C++-class I've written that resembles Win32
>
> <200 lines of grossly verbose (worse than COBOL) C++ elided>
>
> This is comp.lang.c.

It's about the general algorithms of timestamp-conversion.
Ther wouldn't be a huge difference if they were implemented in C.

Am 01.03.2022 um 17:42 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> Here's a nice C++-class I've written that resembles Win32
>
> <200 lines of grossly verbose (worse than COBOL) C++ elided>

And my code isn't worse than cobol but extremely readable.
Your code is a piece of shit.

Am 01.03.2022 um 17:42 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> Here's a nice C++-class I've written that resembles Win32
>
> <200 lines of grossly verbose (worse than COBOL) C++ elided>

And the verbosity comes from a personality than can combine verbal
thinking and logical thinking good. Cryptic coding usually comes
from poor minds which can't combine this skills.