Tomorrow is 22.02.2022, unless you use the US convention, in which case
you will have to wait until 2220.

On 14:02 21 Feb 2022, occam said:
>
> Tomorrow is 22.02.2022, unless you use the US convention, in which case
> you will have to wait until 2220.

Thanks. :)

On Mon, 21 Feb 2022 15:02:02 +0100, occam <nobody@nowhere.nix> wrote:

>
>Tomorrow is 22.02.2022, unless you use the US convention, in which case
>you will have to wait until 2220.

I use the US convention, but I think both it and the UK convention are
inferior to 2022.02.22, which is directly sortable.

As much as I might like to wait until 2220, it's highly unlikely that
I will get there.

On Monday, February 21, 2022 at 11:38:32 AM UTC-6, Ken Blake wrote:
> On Mon, 21 Feb 2022 15:02:02 +0100, occam <nob...@nowhere.nix> wrote:
>
> >
> >Tomorrow is 22.02.2022, unless you use the US convention, in which case
> >you will have to wait until 2220.
> I use the US convention, but I think both it and the UK convention are
> inferior to 2022.02.22, which is directly sortable.
>
> As much as I might like to wait until 2220, it's highly unlikely that
> I will get there.

My plan is to not die. It's working so far.

In message <0cj71hdop8mg3tjedjv9i7v04bfqpkp424@4ax.com> Ken Blake <Ken@invalid.news.com> wrote:
> On Mon, 21 Feb 2022 15:02:02 +0100, occam <nobody@nowhere.nix> wrote:

>>
>>Tomorrow is 22.02.2022, unless you use the US convention, in which case
>>you will have to wait until 2220.

No, because the US (idiotic) convention does not use a leading zero.

> I use the US convention, but I think both it and the UK convention are
> inferior to 2022.02.22, which is directly sortable.

If sorting is what is needed, then sorting order is important. If
readability is what is needed, then sorting order is not important and
it is better to have the most relevant information first.

For example, when I have a movie on my server I style the name

"The Inglorious Bastards (1978)"

Sortability of the movie by year is largely useless for finding a movie,
so that information is last.

> As much as I might like to wait until 2220, it's highly unlikely that
> I will get there.

So far, so good.

--
WORDS IN THE HEART CANNOT BE TAKEN --Feet of Clay

On Tue, 22 Feb 2022 05:31:01 -0000 (UTC), Lewis
<g.kreme@kreme.dont-email.me> wrote:

>In message <0cj71hdop8mg3tjedjv9i7v04bfqpkp424@4ax.com> Ken Blake <Ken@invalid.news.com> wrote:
>> On Mon, 21 Feb 2022 15:02:02 +0100, occam <nobody@nowhere.nix> wrote:
>
>>>
>>>Tomorrow is 22.02.2022, unless you use the US convention, in which case
>>>you will have to wait until 2220.
>
>No, because the US (idiotic) convention does not use a leading zero.

It often does. If I were signing my name on a document along with a
date, no, I would not use a leading zero. But if I were filling in a
form on the web (and often on paper forms) the leading zero would
probably be required,

>> I use the US convention, but I think both it and the UK convention are
>> inferior to 2022.02.22, which is directly sortable.
>
>If sorting is what is needed, then sorting order is important. If
>readability is what is needed, then sorting order is not important and
>it is better to have the most relevant information first.
>
>For example, when I have a movie on my server I style the name
>
>"The Inglorious Bastards (1978)"
>
>Sortability of the movie by year is largely useless for finding a movie,
>so that information is last.
>
>> As much as I might like to wait until 2220, it's highly unlikely that
>> I will get there.
>
>So far, so good.

On 22/02/22 01:02, occam wrote:
>
> Tomorrow is 22.02.2022, unless you use the US convention, in which
> case you will have to wait until 2220.

I see that one group in Newcastle marked the date with dancers in tutus.

But they reported the date as 22/2/22. Apparently the use of two-dgit
years has not yet died out.

--
Peter Moylan Newcastle, NSW http://www.pmoylan.org

In message <sv3v1c$pl4$1@dont-email.me> Peter Moylan <peter@pmoylan.org.invalid> wrote:
> On 22/02/22 01:02, occam wrote:
>>
>> Tomorrow is 22.02.2022, unless you use the US convention, in which
>> case you will have to wait until 2220.

> I see that one group in Newcastle marked the date with dancers in tutus.

> But they reported the date as 22/2/22. Apparently the use of two-dgit
> years has not yet died out.

It never will.

--
"Are you pondering what I'm pondering?"
"I think so, Brain. But if he left chocolate bullets instead of
silver, they'd get all runny and gooey!"

On 23/02/22 11:39, Lewis wrote:
> In message <sv3v1c$pl4$1@dont-email.me> Peter Moylan
> <peter@pmoylan.org.invalid> wrote:
>> On 22/02/22 01:02, occam wrote:
>>>
>>> Tomorrow is 22.02.2022, unless you use the US convention, in
>>> which case you will have to wait until 2220.
>
>> I see that one group in Newcastle marked the date with dancers in
>> tutus.
>
>> But they reported the date as 22/2/22. Apparently the use of
>> two-dgit years has not yet died out.
>
> It never will.

A computer programmer had himself put in cold sleep. When they
eventually woke him up, the first thing they said was "Do you know COBOL?"

"Yes", he said. "Why do you ask?"

"Well, it's now the year 9999, ..."

An AUE regular (I forget who it was) worked on the Y2K problem, and
specifically on the problem of storing 4-digit years on credit cards.
According to him, they went back to 2-digit years in about 2002.

In my genealogy studies, I have occasionally run into 2-digit years on
things like birth registrations. I _think_ the people concerned lived in
the 19th century, but can never be sure.

--
Peter Moylan Newcastle, NSW http://www.pmoylan.org

On Monday, February 21, 2022 at 7:02:09 AM UTC-7, occam wrote:

> Tomorrow is 22.02.2022, unless you use the US convention, in which case
> you will have to wait until 2220.

The cashier at the drug store wished me a happy twos day. (That may work
better in some dialects than others.)

--
Jerry Friedman

On Tuesday, February 22, 2022 at 8:47:43 PM UTC-6, Jerry Friedman wrote:
> On Monday, February 21, 2022 at 7:02:09 AM UTC-7, occam wrote:
>
> > Tomorrow is 22.02.2022, unless you use the US convention, in which case
> > you will have to wait until 2220.
> The cashier at the drug store wished me a happy twos day. (That may work
> better in some dialects than others.)

Clever. It doesn't rhyme for me, but the meaning is clear enough.

A local radio station's presenters were going on and on about the date.
None of what they were saying was in reference to it being palindromic.

However, a listener called in and said that today is 'a mirror day', and
when they asked her what it meant, she said that according to one or
more social media conversation, you were supposed to think good thoughts
and show kindness toward people, and it would be "mirrored back to you'.

>
> --
> Jerry Friedman

On Wed, 23 Feb 2022 12:03:15 +1100, Peter Moylan
<peter@pmoylan.org.invalid> wrote:

>On 23/02/22 11:39, Lewis wrote:
>> In message <sv3v1c$pl4$1@dont-email.me> Peter Moylan
>> <peter@pmoylan.org.invalid> wrote:
>>> On 22/02/22 01:02, occam wrote:
>>>>
>>>> Tomorrow is 22.02.2022, unless you use the US convention, in
>>>> which case you will have to wait until 2220.
>>
>>> I see that one group in Newcastle marked the date with dancers in
>>> tutus.
>>
>>> But they reported the date as 22/2/22. Apparently the use of
>>> two-dgit years has not yet died out.
>>
>> It never will.
>
>A computer programmer had himself put in cold sleep. When they
>eventually woke him up, the first thing they said was "Do you know COBOL?"
>
>"Yes", he said. "Why do you ask?"
>
>"Well, it's now the year 9999, ..."
>
>An AUE regular (I forget who it was) worked on the Y2K problem, and

I never worked to remedy the Y2K problem (2000 was well after I
retired), but I lectured on it several times, mostly explaining what's
below.

>specifically on the problem of storing 4-digit years on credit cards.
>According to him, they went back to 2-digit years in about 2002.

In my view, the main reason for the Y2K 2-digit year problem was that
4-digit years took up more space. I started programming in 1962, on a
4K IBM 1401 (4000, not 4096; I would have loved to have an extra 96
bytes), which grew to 8K, then 12K.

The difference between 2 and 4 sound like only 2, but it was much
more. Tapes were blocked, and a typical tape might be written in
blocks of 10 with space in the program for two blocks. So if a program
was updating a master tape, the input master tape might be 20x2 extra
bytes, the output master tape might be 20x2 extra bytes, the
transaction tape might be 20x2 extra bytes, and the work area for
updating was 2 extra bytes. That's 122 extra bytes. With only 4000
bytes for a program, 122 bytes was a *lot*. So we were almost forced
to use 2-digit years.

The 1401 was the most popular computer back then, so that problem was
very common.

On 24/02/22 03:48, Ken Blake wrote:
> On Wed, 23 Feb 2022 12:03:15 +1100, Peter Moylan
> <peter@pmoylan.org.invalid> wrote:

>> A computer programmer had himself put in cold sleep. When they
>> eventually woke him up, the first thing they said was "Do you know
>> COBOL?"
>>
>> "Yes", he said. "Why do you ask?"
>>
>> "Well, it's now the year 9999, ..."
>>
>> An AUE regular (I forget who it was) worked on the Y2K problem,
>> and
>
>
> I never worked to remedy the Y2K problem (2000 was well after I
> retired), but I lectured on it several times, mostly explaining
> what's below.
>
>> specifically on the problem of storing 4-digit years on credit
>> cards. According to him, they went back to 2-digit years in about
>> 2002.
>
> In my view, the main reason for the Y2K 2-digit year problem was
> that 4-digit years took up more space. I started programming in 1962,
> on a 4K IBM 1401 (4000, not 4096; I would have loved to have an extra
> 96 bytes), which grew to 8K, then 12K.
>
> The difference between 2 and 4 sound like only 2, but it was much
> more. Tapes were blocked, and a typical tape might be written in
> blocks of 10 with space in the program for two blocks. So if a
> program was updating a master tape, the input master tape might be
> 20x2 extra bytes, the output master tape might be 20x2 extra bytes,
> the transaction tape might be 20x2 extra bytes, and the work area
> for updating was 2 extra bytes. That's 122 extra bytes. With only
> 4000 bytes for a program, 122 bytes was a *lot*. So we were almost
> forced to use 2-digit years.
>
> The 1401 was the most popular computer back then, so that problem
> was very common.

That's why they produced Y2KY Jelly, for those who needed to insert two
extra digits.

Part of the problem was the attitude that software should last forever,
and not be updated to reflect changing circumstances. The management
attitude was that they had already put the investment into developing a
product, and that that product should continue to operate in place long
after the original programmers had retired, so that there was nobody
around who knew how to maintain it anyway.

Of course, there's a lot to be said for "If it ain't broke, don't fix
it"; but if there's a problem with faulty date comparisons, then it was
indeed broke, and needed fixing.

The problem is still around. A lot of existing C software will be broken
if the C data type time_t is redefined. That means that there will be a
massive panic in the year 2037, which isn't far in the future. Some
programmers have thought ahead about this problem; others haven't.

--
Peter Moylan Newcastle, NSW http://www.pmoylan.org

Peter Moylan:
> That's why they produced Y2KY Jelly, for those who needed to insert two
> extra digits.

(Groan.)
> Part of the problem was the attitude that software should last forever,
> and not be updated to reflect changing circumstances...
> Of course, there's a lot to be said for "If it ain't broke, don't fix
> it"; but if there's a problem with faulty date comparisons, then it was
> indeed broke, and needed fixing.

Indeed.
> The problem is still around. A lot of existing C software will be broken
> if the C data type time_t is redefined.

time_t is not a C data type. It is a data type -- an arithmetic
type capable of representing times -- that the standard requires
each C implementation to define.
--
Mark Brader, Toronto | "It's easier to deal with 'opposite numbers'
msb@vex.net | when you know you cannot trust them." --Chess

My text in this article is in the public domain.

On 23/02/2022 4:48 pm, Ken Blake wrote:
> On Wed, 23 Feb 2022 12:03:15 +1100, Peter Moylan
> <peter@pmoylan.org.invalid> wrote:
>
>> On 23/02/22 11:39, Lewis wrote:
>>> In message <sv3v1c$pl4$1@dont-email.me> Peter Moylan
>>> <peter@pmoylan.org.invalid> wrote:
>>>> On 22/02/22 01:02, occam wrote:
>>>>>
>>>>> Tomorrow is 22.02.2022, unless you use the US convention, in
>>>>> which case you will have to wait until 2220.
>>>
>>>> I see that one group in Newcastle marked the date with dancers in
>>>> tutus.
>>>
>>>> But they reported the date as 22/2/22. Apparently the use of
>>>> two-dgit years has not yet died out.
>>>
>>> It never will.
>>
>> A computer programmer had himself put in cold sleep. When they
>> eventually woke him up, the first thing they said was "Do you know COBOL?"
>>
>> "Yes", he said. "Why do you ask?"
>>
>> "Well, it's now the year 9999, ..."
>>
>> An AUE regular (I forget who it was) worked on the Y2K problem, and
>
>
> I never worked to remedy the Y2K problem

I did.

(2000 was well after I
> retired), but I lectured on it several times, mostly explaining what's
> below.
>
>
>> specifically on the problem of storing 4-digit years on credit cards.
>> According to him, they went back to 2-digit years in about 2002.
>
>
> In my view, the main reason for the Y2K 2-digit year problem was that
> 4-digit years took up more space. I

2-digit years are typically stored in six octets: DDMMYY. Using days
since an index date, in four octets you can store 2^32 days, which is
2^32 / 365 = 11767033 years.

So no, storage wasn't the problem, because if storage really were the
problem there was a solution right there. No, the real problem was that
it never occurred to anyone that their code would still be running 40
years later. And then 39 years, and 38... It was only when the number
wore down enough that the penny finally dropped.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

On 23/02/2022 11:47 pm, Peter Moylan wrote:
> On 24/02/22 03:48, Ken Blake wrote:
>> On Wed, 23 Feb 2022 12:03:15 +1100, Peter Moylan
>> <peter@pmoylan.org.invalid> wrote:
>
>>> A computer programmer had himself put in cold sleep. When they
>>> eventually woke him up, the first thing they said was "Do you know
>>> COBOL?"
>>>
>>> "Yes", he said. "Why do you ask?"
>>>
>>> "Well, it's now the year 9999, ..."
>>>
>>> An AUE regular (I forget who it was) worked on the Y2K problem,
>>> and
>>
>>
>> I never worked to remedy the Y2K problem (2000 was well after I
>> retired), but I lectured on it several times, mostly explaining
>> what's below.
>>
>>> specifically on the problem of storing 4-digit years on credit
>>> cards. According to him, they went back to 2-digit years in about
>>> 2002.
>>
>> In my view, the main reason for the Y2K 2-digit year problem was
>> that 4-digit years took up more space. I started programming in 1962,
>> on a 4K IBM 1401 (4000, not 4096; I would have loved to have an extra
>> 96 bytes), which grew to 8K, then 12K.
>>
>> The difference between 2 and 4 sound like only 2, but it was much
>> more. Tapes were blocked, and a typical tape might be written in
>> blocks of 10 with space in the program for two blocks. So if a
>> program was updating a master tape, the input master tape might be
>> 20x2 extra bytes, the output master tape might be 20x2 extra bytes,
>> the transaction tape might be 20x2 extra bytes, and the work area
>> for updating was 2 extra bytes. That's 122 extra bytes. With only
>> 4000 bytes for a program, 122 bytes was a *lot*. So we were almost
>> forced to use 2-digit years.
>>
>> The 1401 was the most popular computer back then, so that problem
>> was very common.
>
> That's why they produced Y2KY Jelly, for those who needed to insert two
> extra digits.
>
> Part of the problem was the attitude that software should last forever,
> and not be updated to reflect changing circumstances. The management
> attitude was that they had already put the investment into developing a
> product, and that that product should continue to operate in place long
> after the original programmers had retired, so that there was nobody
> around who knew how to maintain it anyway.
>
> Of course, there's a lot to be said for "If it ain't broke, don't fix
> it"; but if there's a problem with faulty date comparisons, then it was
> indeed broke, and needed fixing.
>
> The problem is still around. A lot of existing C software will be broken
> if the C data type time_t is redefined.

It hasn't been. The C Standard defines it only as an arithmetic type
capable of representing times (see ISO/IEC 9899 7.23.1(3)). The wording
hasn't changed since 1989.

> That means that there will be a
> massive panic in the year 2037, which isn't far in the future.

Is that true? Let's find out.

#include <stdio.h>
#include <string.h>
#include <time.h>

static void now(const char *s, time_t *t)
{ char date[16];
struct tm *fd;

fd = localtime(t);
strftime(date, sizeof date, "%F", fd);

printf("%s: %s\n", s, date);
}

int main(void)
{ time_t t = {0};

printf("Size (octets): %d\n", (int)sizeof t);

t = (time_t)-9999999999;
now(" Long ago", &t);
t = (time_t)9999999999;
now("Some day soon", &t);

printf("\n\n\nBut why stop there?\n\n\n");

t = (time_t)-99999999999;
now(" Longer ago", &t);
t = (time_t)99999999999;
now("Some days later", &t);

return 0;
}

$ gcc -o tt tt.c
$ ./tt
Size (octets): 8
Long ago: 1653-02-10
Some day soon: 2286-11-20

But why stop there?

Longer ago: -1199-02-15
Some days later: 5138-11-16

And I could have gone further. A lot further.

Clearly, C's definition of time_t is not the problem.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

On 24/02/22 12:35, Mark Brader wrote:
> Peter Moylan:

>> The problem is still around. A lot of existing C software will be
>> broken if the C data type time_t is redefined.
>
> time_t is not a C data type. It is a data type -- an arithmetic type
> capable of representing times -- that the standard requires each C
> implementation to define.

True; but a lot of oldish software was built on platforms that defined
time_t to be a 32-bit type. That software needs to be rebuilt, probably
with a new compiler. Occasionally, the change in a data type can
snowball all over the place. Not an insoluble problem for a competent
programmer, but someone needs to identify which programs have to be
fixed, and to assign people to do the fix.

No big deal when it's just one program, but those little bits really add up.

I don't think any statistics were kept for the Y2K problem, but I'm sure
that it created extra work for hundreds and possibly thousands of
programmers. The biggest part of the job will be identifying what needs
fixing.

And we can be pretty certain that most of this work will be delayed
until the last minute.

--
Peter Moylan Newcastle, NSW http://www.pmoylan.org

Peter Moylan:
>>> The problem is still around. A lot of existing C software will be
>>> broken if the C data type time_t is redefined.

Mark Brader:
>> time_t is not a C data type. It is a data type -- an arithmetic type
>> capable of representing times -- that the standard requires each C
>> implementation to define.
Peter Moylan:
> True; but a lot of oldish software was built on platforms that defined
> time_t to be a 32-bit type.

If so, then time_t has *already* been redefined, so you wrote in the
wrong tense.
--
Mark Brader "Remember, this is Mark we're dealing with.
Toronto Rationality and fact won't work very well."
msb@vex.net -- Jeff Scott Franzman

On Thu, 24 Feb 2022 16:04:46 +1100
Peter Moylan <peter@pmoylan.org.invalid> wrote:

> On 24/02/22 12:35, Mark Brader wrote:
> > Peter Moylan:
>
> >> The problem is still around. A lot of existing C software will be
> >> broken if the C data type time_t is redefined.
> >
> > time_t is not a C data type. It is a data type -- an arithmetic type
> > capable of representing times -- that the standard requires each C
> > implementation to define.
>
> True; but a lot of oldish software was built on platforms that defined
> time_t to be a 32-bit type. That software needs to be rebuilt, probably
[]
>
> And we can be pretty certain that most of this work will be delayed
> until the last minute.
>
I'll Second that:
[Like]

--
Bah, and indeed Humbug.

In message <sv73lh$8a3$1@dont-email.me> Peter Moylan <peter@pmoylan.org.invalid> wrote:
> On 24/02/22 12:35, Mark Brader wrote:
>> Peter Moylan:

>>> The problem is still around. A lot of existing C software will be
>>> broken if the C data type time_t is redefined.
>>
>> time_t is not a C data type. It is a data type -- an arithmetic type
>> capable of representing times -- that the standard requires each C
>> implementation to define.

> True; but a lot of oldish software was built on platforms that defined
> time_t to be a 32-bit type.

31 bits (well, 32 bit signed, so the first bit indicates positive or
negative numbers. This allows 2,147,483,647 seconds which is why 2038
is the next critical date issue as that is when the Unix epoch rolls
over.

If it were 32 bits unsigned, we'd not be rolling the epoch until about
2100.

> That software needs to be rebuilt, probably with a new compiler.
> Occasionally, the change in a data type can snowball all over the
> place. Not an insoluble problem for a competent programmer, but
> someone needs to identify which programs have to be fixed, and to
> assign people to do the fix.

There was a huge issue recently with Microsoft because they use the
pattern YYMMDDHHMM as an 31 bit integer value, which meant that their
Windows update failed when the year rolled to 22, the number overflowed
and the update process crashed. Had they at least used an unsigned
integer, the problem would not have been discovered until 2042.

Why anyone would be so astonishingly stupid to store a date like that is
another question, but it appears that Microsoft was not the only company
to have this issue. I like to think it may have been a single programmer
who worked at several companies who thought this was a clever idea.

> No big deal when it's just one program, but those little bits really add up.

In very unexpected ways, as above.

> I don't think any statistics were kept for the Y2K problem, but I'm sure
> that it created extra work for hundreds and possibly thousands of
> programmers. The biggest part of the job will be identifying what needs
> fixing.

It was a huge task that was amazingly successful, so of course it has
been largely forgotten as "no big deal".

> And we can be pretty certain that most of this work will be delayed
> until the last minute.

At least for Unix, the date routines have been moved to 64 bit (still
signed) which will last us a reasonably long time, about 292,277,266,000
years.

It is, of course, all slightly more complicated than this, as the day is
not exactly 86,400 seconds, and the synchronizing of the Unix time with
the Earth's time takes quite a lot of adjustment (leap seconds) that
have to be accounted for in calculating the current Unix time.

Interestingly, even though the Unix time is a signed integer, it is
still generally impossible to time-stamp a file with a negative date.
So, for example, I can set the date of movie files to their release
dates only for movies released in 1970 or later and I can set TV
episodes time stamps to the time and date they were first broadcast only
for 70s and later TV show, so The Aadams Family and Dick Van Dyke Show
episodes have to suffer with the wrong timestamps.

--
Worlds on worlds are rolling ever From creation to decay, Like the
bubbles on a river Sparkling, bursting, borne away. -- Shelly

On Tue, 22 Feb 2022 18:47:38 -0800 (PST), Jerry Friedman
<jerry_friedman@yahoo.com> wrote:

>On Monday, February 21, 2022 at 7:02:09 AM UTC-7, occam wrote:
>
>> Tomorrow is 22.02.2022, unless you use the US convention, in which case
>> you will have to wait until 2220.
>
>The cashier at the drug store wished me a happy twos day. (That may work
>better in some dialects than others.)

I've seen two news reports of babies born on 22.02.2022.
The first was said to have been born at 2.22 on 22.02.2022.
The other was of twins born on "Twosay".

Of course there will have been many, many, more born on that day.

--
Peter Duncanson, UK
(in alt.usage.english)

On Thursday, February 24, 2022 at 7:43:02 AM UTC-5, PeterWD wrote:
> On Tue, 22 Feb 2022 18:47:38 -0800 (PST), Jerry Friedman
> <jerry_f...@yahoo.com> wrote:
>
> >On Monday, February 21, 2022 at 7:02:09 AM UTC-7, occam wrote:
> >
> >> Tomorrow is 22.02.2022, unless you use the US convention, in which case
> >> you will have to wait until 2220.
> >
> >The cashier at the drug store wished me a happy twos day. (That may work
> >better in some dialects than others.)
> I've seen two news reports of babies born on 22.02.2022.
> The first was said to have been born at 2.22 on 22.02.2022.

I guess that's 2:22 instead of 14:22.

On 24/02/22 22:54, Lewis wrote:
> In message <sv73lh$8a3$1@dont-email.me> Peter Moylan
> <peter@pmoylan.org.invalid> wrote:
>> On 24/02/22 12:35, Mark Brader wrote:
>>> Peter Moylan:
>
>>>> The problem is still around. A lot of existing C software will
>>>> be broken if the C data type time_t is redefined.
>>>
>>> time_t is not a C data type. It is a data type -- an arithmetic
>>> type capable of representing times -- that the standard requires
>>> each C implementation to define.
>
>> True; but a lot of oldish software was built on platforms that
>> defined time_t to be a 32-bit type.
>
> 31 bits (well, 32 bit signed, so the first bit indicates positive or
> negative numbers. This allows 2,147,483,647 seconds which is why
> 2038 is the next critical date issue as that is when the Unix epoch
> rolls over.
>
> If it were 32 bits unsigned, we'd not be rolling the epoch until
> about 2100.

Which would be more convenient, because then the seconds overflow
problem could be tackled in parallel with the 2-digit year problem,
leading to a more efficient allocation of programmers to jobs.

But there is, for some reason, a tradition of using signed integers in
situations where unsigned would seem more logical. (Although I concede
that signed time values would allow the use of dates before 1970.) In my
own programming, almost all integers are unsigned. It's quite
surprising, when you first notice it, how rarely signed integers are
needed in practice.

There is a silly problem that arises when interfacing between Modula-2
(a strongly typed language) and C (a weakly typed language). One often
meets C library functions that return an _unsigned_ integer with value
-1. To test for that value in Modula-2, you have to compare with the
value MAX(CARDINAL), because Modula-2 does not consider -1 to be an
unsigned number.

> Interestingly, even though the Unix time is a signed integer, it is
> still generally impossible to time-stamp a file with a negative
> date.

Yes, because the original programmers were thinking "unsigned" at the
time they specified "signed". You have the same problem with negative
file sizes.

--
Peter Moylan Newcastle, NSW http://www.pmoylan.org

On Thu, 24 Feb 2022 04:59:15 -0800 (PST), bruce bowser
<bruce2bowser@gmail.com> wrote:

>On Thursday, February 24, 2022 at 7:43:02 AM UTC-5, PeterWD wrote:
>> On Tue, 22 Feb 2022 18:47:38 -0800 (PST), Jerry Friedman
>> <jerry_f...@yahoo.com> wrote:
>>
>> >On Monday, February 21, 2022 at 7:02:09 AM UTC-7, occam wrote:
>> >
>> >> Tomorrow is 22.02.2022, unless you use the US convention, in which case
>> >> you will have to wait until 2220.
>> >
>> >The cashier at the drug store wished me a happy twos day. (That may work
>> >better in some dialects than others.)
>> I've seen two news reports of babies born on 22.02.2022.
>> The first was said to have been born at 2.22 on 22.02.2022.
>
>I guess that's 2:22 instead of 14:22.

I assume so.

--
Peter Duncanson, UK
(in alt.usage.english)