On 64-bit systems (which is what most of us would be running by now),
there would be absolutely no difference in the code with this setting.
So the change in package name is I think only to maintain
compatibility with 32-bit architectures.
Linux runs on billions of embedded systems, many of them being a 32 bit architecture and bound to stay there. Embedded systems tend to have an
order of magnitude more in lifetime.
¹ we, Debian, as I am a Debian Developer
On Mon, 15 Apr 2024 08:06:12 +0200, Marc Haber wrote:
Linux runs on billions of embedded systems, many of them being a 32 bit
architecture and bound to stay there. Embedded systems tend to have an
order of magnitude more in lifetime.
And most of those systems will never have their OSes updated. Most vendors >of embedded systems seem to develop their products with a “ship and >forget” mentality.
¹ we, Debian, as I am a Debian Developer
Greetings, and thanks, to the mother of all distros. ;)
The change in package name for 64 bit architectures is because the
build process for .deb packages is essentially the same regardless of
the architecture it happens for. Rebuilding the entire archive on
64bit systems is a largely automated process, while building
infrastructure to have different build processes, dependencies and
package names depending on architecture bit width is something that
must be done by humans.
On Mon, 15 Apr 2024 08:06:12 +0200, Marc Haber wrote:
Linux runs on billions of embedded systems, many of them being a 32 bit
architecture and bound to stay there. Embedded systems tend to have an
order of magnitude more in lifetime.
And most of those systems will never have their OSes updated. Most vendors
of embedded systems seem to develop their products with a “ship and forget” mentality.
Amen¹ we, Debian, as I am a Debian Developer
Greetings, and thanks, to the mother of all distros. ;)
Lately, in Debian Unstable, I have noticed package names starting toIf they use packages from Testing or Sid (both unstable version still
appear with “t64” on the ends. No doubt this will percolate through to Debian derivatives as well.
I wondered what this was about, and foundWhich is important because if it fails, it should be noticed before it
this forum thread <https://www.antixforum.com/forums/topic/t64-at-the-end-of-a-package-title/>.
This has to do with the “year-2038” problem, which should only affect 32-bit systems anyway. But it seems some people are sufficiently
concerned about this to ensure that their code will build with a
64-bit size for time_t (the POSIX type for holding the number of
seconds since 1st January 1970), even on 32-bit systems.
On Mon, 15 Apr 2024 08:06:12 +0200, Marc Haber wrote:That is their problem. A fix is being available - if vendors refuse to
Linux runs on billions of embedded systems, many of them being a 32
bit architecture and bound to stay there. Embedded systems tend to
have an order of magnitude more in lifetime.
And most of those systems will never have their OSes updated. Most
vendors of embedded systems seem to develop their products with a
“ship and forget” mentality.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:The will start caring at least when it breaks. But then they will have
On Mon, 15 Apr 2024 08:06:12 +0200, Marc Haber wrote:
Linux runs on billions of embedded systems, many of them being a 32
bit architecture and bound to stay there. Embedded systems tend to
have an order of magnitude more in lifetime.
And most of those systems will never have their OSes updated. Most
vendors of embedded systems seem to develop their products with a
“ship and forget” mentality.
So it depends if the vendors (and users, who are often negligent about upgrades) care about them still working properly from 2038 onwards.
On 15/04/2024 07:52, Lawrence D'Oliveiro wrote:I know that and I know that they have beads of sweat on their forehead
On Mon, 15 Apr 2024 08:06:12 +0200, Marc Haber wrote:
Linux runs on billions of embedded systems, many of them being a
32 bit architecture and bound to stay there. Embedded systems tend
to have an order of magnitude more in lifetime.
And most of those systems will never have their OSes updated. Most
vendors of embedded systems seem to develop their products with a
“ship and forget” mentality.
Many pieces of industrial gear still run on DOS
you dont upgrade kit that works, for functionality, only to fixIf the time doesn't work properly, many things are broken, especially
problems
I don't know whether we² are going to transition back to theI think this will break many 3rd party package dependencies. It already
unsuffixed names of packages and symbols once all libraries are 64bit
time_t. Personally, I'd consider that a waste.
On 15.04.2024 um 10:55 Uhr Marc Haber wrote:
I don't know whether we² are going to transition back to the
unsuffixed names of packages and symbols once all libraries are 64bit
time_t. Personally, I'd consider that a waste.
I think this will break many 3rd party package dependencies. It already
did with Seafile.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Mon, 15 Apr 2024 08:06:12 +0200, Marc Haber wrote:
Linux runs on billions of embedded systems, many of them being a 32 bit
architecture and bound to stay there. Embedded systems tend to have an
order of magnitude more in lifetime.
And most of those systems will never have their OSes updated. Most vendors >>of embedded systems seem to develop their products with a “ship and >>forget” mentality.
That makes it even more important to think NOW about year 2038.
¹ we, Debian, as I am a Debian Developer
Greetings, and thanks, to the mother of all distros. ;)
*bow*
Greetings
Marc
Many pieces of industrial gear still run on DOS
you dont upgrade kit that works, for functionality, only to fix problems
I don't know whether we² are going to transition back to the unsuffixed names of packages and symbols once all libraries are 64bit time_t. Personally, I'd consider that a waste.
On Mon, 15 Apr 2024 11:34:28 +0100, The Natural Philosopher wrote:
Many pieces of industrial gear still run on DOS
Would you entrust mission-critical business functions to obsolete, unsupported software?
SFMTA's train system running on floppy disks; city fears
'catastrophic failure' before upgrade
On Mon, 15 Apr 2024 11:34:28 +0100, The Natural Philosopher wrote:People trust a lot of things to WIN XP
Many pieces of industrial gear still run on DOS
Would you entrust mission-critical business functions to obsolete, unsupported software?
you dont upgrade kit that works, for functionality, only to fix problems
The trouble with “if it ain’t broke, don’t fix it” is when you wait until
it *is* broke, and only then discover that you have no idea how to fix it.
On 15.04.2024 um 22:15 Uhr Rich wrote:
SFMTA's train system running on floppy disks; city fears
'catastrophic failure' before upgrade
Exactly that is the result of "never change a running system". Spare
parts are often not available and if it breaks, it is hard to fix it.
On 2024-04-15, Rich wrote:
In comp.os.linux.misc Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Mon, 15 Apr 2024 11:34:28 +0100, The Natural Philosopher wrote:
Many pieces of industrial gear still run on DOS
Would you entrust mission-critical business functions to obsolete,
unsupported software?
TNP might not, but that does not change the fact that TNP's statement
is all too true. There is much industrial gear that runs on DOS (or
other, now extinct, OS'es).
A recent (related) example that made the rounds a week or two ago:
SFMTA's train system running on floppy disks; city fears 'catastrophic failure' before upgrade
https://abc7news.com/san-francisco-train-system-has-been-running-on-floppy-disks-but-city-fears-catastrophic-failure-before-upgrade/14624828/
Still relying on floppy disks 26 years later.
One thing about this topic that has been popping up in several
outlets... as El Reg points out in [1]:
«The agency noted that its system was installed in 1998, when
floppies were still in common use and, er, "computers didn't have
hard drives." *That doesn't exactly match reality*,»
(emphasis mine) What happened, somebody mixed the years or tried to make
up an explanation and came up with a bad one? Or am I missing context?
IIRC hard drives were commonplace in 1998, even if not so large.
[1] https://www.theregister.com/2024/04/09/san_francisco_muni_floppy_disks/
Nuno Silva <nunojsilva@invalid.invalid> writes:
One thing about this topic that has been popping up in several
outlets... as El Reg points out in [1]:
«The agency noted that its system was installed in 1998, when
floppies were still in common use and, er, "computers didn't have
hard drives." *That doesn't exactly match reality*,»
(emphasis mine) What happened, somebody mixed the years or tried to make
up an explanation and came up with a bad one? Or am I missing context?
IIRC hard drives were commonplace in 1998, even if not so large.
[1] https://www.theregister.com/2024/04/09/san_francisco_muni_floppy_disks/
The disks are 5.25” disks and that does put the origins of the
technology back into an era where hard drives were at least much less
common - but certainly very long in the tooth by the time the system was deployed.
Other parts of the ATCS also date back to the 1970s, the disks aren’t
even the oldest component.
References:
https://www.sfmta.com/projects/train-control-upgrade-project and https://sfstandard.com/2023/02/02/sfs-market-street-subway-runs-on-reagan-era-floppy-disks/
https://www.railwayage.com/news/muni-atcs-replacement-under-way/, https://en.wikipedia.org/wiki/SelTrac
Nuno Silva <nunojsilva@invalid.invalid> writes:
One thing about this topic that has been popping up in several
outlets... as El Reg points out in [1]:
«The agency noted that its system was installed in 1998, when
floppies were still in common use and, er, "computers didn't have
hard drives." *That doesn't exactly match reality*,»
(emphasis mine) What happened, somebody mixed the years or tried to make
up an explanation and came up with a bad one? Or am I missing context?
IIRC hard drives were commonplace in 1998, even if not so large.
[1] https://www.theregister.com/2024/04/09/san_francisco_muni_floppy_disks/
The disks are 5.25” disks and that does put the origins of the
technology back into an era where hard drives were at least much less
common - but certainly very long in the tooth by the time the system was deployed.
On Mon, 15 Apr 2024 11:34:28 +0100, The Natural Philosopher wrote:
Many pieces of industrial gear still run on DOS
Would you entrust mission-critical business functions to obsolete, unsupported software?
you dont upgrade kit that works, for functionality, only to fix problems
The trouble with “if it ain’t broke, don’t fix it” is when you wait until
it *is* broke, and only then discover that you have no idea how to fix it.
On 15/04/2024 23:09, Lawrence D'Oliveiro wrote:
On Mon, 15 Apr 2024 11:34:28 +0100, The Natural Philosopher wrote:People trust a lot of things to WIN XP
Many pieces of industrial gear still run on DOS
Would you entrust mission-critical business functions to obsolete,
unsupported software?
Freedos is supported
But you completely missed the point. If a piece of hardware and software works as intended, it doesn't matter how 'obsolete or unsupported' it
is. Viz nuclear power stations running on PDP11s and so on.
It is clear you do not actually understand DOS at all: There is nothing
TO support. It is simply a program loader. Everything else is the user application, as DOS allows Assembly language coded bare metal
programming if you want it to.
However, hard disks could break down if used on a vehicle, the
vibrations could destroy them. On a single purpose dedicated machine,
it could make sense to use floppies instead of hard disks.
On Mon, 15 Apr 2024 10:55:16 +0200, Marc Haber wrote:
I don't know whether we² are going to transition back to the unsuffixed
names of packages and symbols once all libraries are 64bit time_t.
Personally, I'd consider that a waste.
You think so? I think it makes sense to get rid of the superfluous suffix, >once it has served its purpose.
On 16.04.2024 um 14:07 Uhr Carlos E.R. wrote:
However, hard disks could break down if used on a vehicle, the
vibrations could destroy them. On a single purpose dedicated machine,
it could make sense to use floppies instead of hard disks.
Floppies are being destroyed slowly when being used because the head
has traction on the floppy disk.
I've seen floppies where that was visible because the area where the
head ran was brighter than the verge.
Also, dust comes in and creates additional attrition.
Moisture is also very bad for them.
I love playing around with such things, but I wouldn't like to have a production system relying on it.
On 2024-04-16 00:09, Lawrence D'Oliveiro wrote:
On Mon, 15 Apr 2024 11:34:28 +0100, The Natural Philosopher wrote:
Many pieces of industrial gear still run on DOS
Would you entrust mission-critical business functions to obsolete,
unsupported software?
On industrial environment, which is not a business environment, yes, I would.
you dont upgrade kit that works, for functionality, only to fix problems
The trouble with “if it ain’t broke, don’t fix it” is when you wait until
it *is* broke, and only then discover that you have no idea how to fix
it.
You don't replace an industrial setup worth millions just because the computer is "obsolete". The computer is just part of it. An industrial
setup is intended to keep working decades.
On 2024-04-16 12:35, The Natural Philosopher wrote:
On 15/04/2024 23:09, Lawrence D'Oliveiro wrote:
On Mon, 15 Apr 2024 11:34:28 +0100, The Natural Philosopher wrote:People trust a lot of things to WIN XP
Many pieces of industrial gear still run on DOS
Would you entrust mission-critical business functions to obsolete,
unsupported software?
Freedos is supported
But you completely missed the point. If a piece of hardware and
software works as intended, it doesn't matter how 'obsolete or
unsupported' it is. Viz nuclear power stations running on PDP11s and
so on.
It is clear you do not actually understand DOS at all: There is
nothing TO support. It is simply a program loader. Everything else is
the user application, as DOS allows Assembly language coded bare metal
programming if you want it to.
And there is no network access to protect from. The thing is as secure
as it was when built. You only have to protect from physical access.
The real problem is hardware breakdown. There are no spares.
Machines installed 1998 could have been designed 5 years before. Using
an actual 8086 in an expensive industrial PC was possible, a Pentium
would be normal.
On 16.04.2024 um 14:07 Uhr Carlos E.R. wrote:
However, hard disks could break down if used on a vehicle, the
vibrations could destroy them. On a single purpose dedicated machine,
it could make sense to use floppies instead of hard disks.
Floppies are being destroyed slowly when being used because the head
has traction on the floppy disk.
I've seen floppies where that was visible because the area where the
head ran was brighter than the verge.
Also, dust comes in and creates additional attrition.
Moisture is also very bad for them.
I love playing around with such things, but I wouldn't like to have a production system relying on it.
On 2024-04-16 15:39, Marco Moock wrote:
On 16.04.2024 um 14:07 Uhr Carlos E.R. wrote:
However, hard disks could break down if used on a vehicle, the
vibrations could destroy them. On a single purpose dedicated machine,
it could make sense to use floppies instead of hard disks.
Floppies are being destroyed slowly when being used because the head
has traction on the floppy disk.
I've seen floppies where that was visible because the area where the
head ran was brighter than the verge.
Also, dust comes in and creates additional attrition.
Moisture is also very bad for them.
I love playing around with such things, but I wouldn't like to have a
production system relying on it.
There was software that kept the floppy drive turning non stop. When I noticed that happening, I just opened the door or stopped the program.
At the time, if you needed to load some data, you had to use floppies.
There were no alternatives. Ok, there were some things, but
significantly more expensive. Mostly magnetic storage.
You could have some industrial machine doing a job; you designed the
task on your desktop, then fed it via floppy to the machine in the
machine shop.
Quite simple :-)
On 16/04/2024 13:11, Carlos E.R. wrote:
On 2024-04-16 00:09, Lawrence D'Oliveiro wrote:Back in the 80s worked on a terrible project - software to go in
On Mon, 15 Apr 2024 11:34:28 +0100, The Natural Philosopher wrote:
Many pieces of industrial gear still run on DOS
Would you entrust mission-critical business functions to obsolete,
unsupported software?
On industrial environment, which is not a business environment, yes, I
would.
you dont upgrade kit that works, for functionality, only to fix
problems
The trouble with “if it ain’t broke, don’t fix it” is when you wait
until
it *is* broke, and only then discover that you have no idea how to
fix it.
You don't replace an industrial setup worth millions just because the
computer is "obsolete". The computer is just part of it. An industrial
setup is intended to keep working decades.
underwater fibre repeaters.
Everything was a muddle, but one of the permies remarked 'at least we
are allowed to use silicon, now'
They had to stick with GERMANIUM until silicon devices had been around
25 years - the guaranteed product life span.
There are still more than a few PDPs and vaxen doing mission critical
stuff out there.
As the saying goes, 'A VAX is like an erect penis, It will stay up as
long as you don't fuck with it'
On 2024-04-16 00:09, Lawrence D'Oliveiro wrote:
The trouble with “if it ain’t broke, don’t fix it” is when you wait >> until it *is* broke, and only then discover that you have no idea how
to fix it.
You don't replace an industrial setup worth millions just because the computer is "obsolete".
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On 64-bit systems (which is what most of us would be running by now),
You need to think beyond your desktop PC. Linux runs on billions of
embedded systems, many of them being a 32 bit architecture and bound
to stay there. Embedded systems tend to have an order of magnitude
more in lifetime. The year 2038 is already here for those systems.
On 2024-04-17 02:42, Lawrence D'Oliveiro wrote:
On Tue, 16 Apr 2024 14:11:05 +0200, Carlos E.R. wrote:
On 2024-04-16 00:09, Lawrence D'Oliveiro wrote:
The trouble with “if it ain’t broke, don’t fix it” is when you wait
until it *is* broke, and only then discover that you have no idea how
to fix it.
You don't replace an industrial setup worth millions just because the
computer is "obsolete".
If you could really afford to spend millions on the hardware, then it
would be peanuts by comparison to add on a software support contract
that will provide maintenance and updates for the expected life of the
hardware.
Which probably they have.
On 17/04/2024 04:27, Lawrence D'Oliveiro wrote:
On Wed, 17 Apr 2024 04:45:43 +0200, Carlos E.R. wrote:
On 2024-04-17 02:42, Lawrence D'Oliveiro wrote:
On Tue, 16 Apr 2024 14:11:05 +0200, Carlos E.R. wrote:
On 2024-04-16 00:09, Lawrence D'Oliveiro wrote:
The trouble with “if it ain’t broke, don’t fix it” is when you wait
until it *is* broke, and only then discover that you have no idea how >>>>>> to fix it.
You don't replace an industrial setup worth millions just because the >>>>> computer is "obsolete".
If you could really afford to spend millions on the hardware, then it
would be peanuts by comparison to add on a software support contract
that will provide maintenance and updates for the expected life of the >>>> hardware.
Which probably they have.
Then the computer is not “obsolete”, if you can still get support for it.
You can still get spare parts for 1950s cars. That doesn't mean they are flawless or not obsolete.
Let's rephrase it. You have a system running on DEC PDP-11s: The guys
who wrote the software are dead, the company that supplied it went out
of business years ago, and no one will even offer a support contract on
it, But it runs your trains perfectly.
To replace it, a large software company quoted you $5m.
What do you do?
On 17/04/2024 04:27, Lawrence D'Oliveiro wrote:
On Wed, 17 Apr 2024 04:45:43 +0200, Carlos E.R. wrote:
On 2024-04-17 02:42, Lawrence D'Oliveiro wrote:
On Tue, 16 Apr 2024 14:11:05 +0200, Carlos E.R. wrote:
On 2024-04-16 00:09, Lawrence D'Oliveiro wrote:
The trouble with “if it ain’t broke, don’t fix it” is when you wait
until it *is* broke, and only then discover that you have no idea how >>>>>> to fix it.
You don't replace an industrial setup worth millions just because the >>>>> computer is "obsolete".
If you could really afford to spend millions on the hardware, then it
would be peanuts by comparison to add on a software support contract
that will provide maintenance and updates for the expected life of the >>>> hardware.
Which probably they have.
Then the computer is not “obsolete”, if you can still get support for it.
You can still get spare parts for 1950s cars. That doesn't mean they are flawless or not obsolete.
Let's rephrase it. You have a system running on DEC PDP-11s: The guys
who wrote the software are dead, the company that supplied it went out
of business years ago, and no one will even offer a support contract on
it, But it runs your trains perfectly.
To replace it, a large software company quoted you $5m.
What do you do?
You have a system running on DEC PDP-11s: The guys
who wrote the software are dead, the company that supplied it went out
of business years ago, and no one will even offer a support contract on
it, But it runs your trains perfectly.
On Wed, 17 Apr 2024 09:16:07 +0100, The Natural Philosopher wrote:
You have a system running on DEC PDP-11s: The guys
who wrote the software are dead, the company that supplied it went out
of business years ago, and no one will even offer a support contract on
it, But it runs your trains perfectly.
If you could really afford to spend millions on the hardware, then it
would be peanuts by comparison to add on a software support contract that will provide maintenance and updates for the expected life of the
hardware.
Software costs way more than hardware.
On Wed, 17 Apr 2024 23:01:36 +0100, The Natural Philosopher wrote:
Software costs way more than hardware.
You’re not suggesting the customer can’t afford to pay for it, are you?
On 18/04/2024 00:23, Lawrence D'Oliveiro wrote:
On Wed, 17 Apr 2024 23:01:36 +0100, The Natural Philosopher wrote:
Software costs way more than hardware.
You’re not suggesting the customer can’t afford to pay for it, are you?
[irrelevant blather about non-business-related products]
On 17/04/2024 22:57, Lawrence D'Oliveiro wrote:
On Wed, 17 Apr 2024 09:16:07 +0100, The Natural Philosopher wrote:
You have a system running on DEC PDP-11s: The guys
who wrote the software are dead, the company that supplied it went out
of business years ago, and no one will even offer a support contract on
it, But it runs your trains perfectly.
If you could really afford to spend millions on the hardware, then it
would be peanuts by comparison to add on a software support contract that
will provide maintenance and updates for the expected life of the
hardware.
Stop wriggling.
Software costs way more than hardware.
That's what you spent the money on, and the support contract with the company
that no longer exists is not worth wiping your bottom with.
I find it fascinating that Lawrence tries to
argue with the guy who was actually there.
I find it fascinating that Lawrence tries to argue with the guy who
was actually there.
On 18/04/2024 00:23, Lawrence D'Oliveiro wrote:
On Wed, 17 Apr 2024 23:01:36 +0100, The Natural Philosopher wrote:
Software costs way more than hardware.
You’re not suggesting the customer can’t afford to pay for it, are
you?
Stop being deliberately obtuse, and thinking like an Apple or
Microsoft customer.
When did you last upgrade the firmware in your watch? What support
contract is there on your washing machine? Is your house still under warranty, or does it simply not have a support contract?
Perhaps you should buy a new one, You can surely afford to.
Marc Haber wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On 64-bit systems (which is what most of us would be running by now),
You need to think beyond your desktop PC. Linux runs on billions of
embedded systems, many of them being a 32 bit architecture and bound
to stay there. Embedded systems tend to have an order of magnitude
more in lifetime. The year 2038 is already here for those systems.
So don't get in an elevator on Jan 18/19 2038?
In comp.os.linux.misc D <nospam@example.net> wrote:
I find it fascinating that Lawrence tries to argue with the guy who
was actually there.
I'm moving more and more with each of Lawrence's responses to the
belief that he is actually trolling. He's not far now from earning a killfile slot of his very own.
Woozy Song <suzyw0ng@outlook.com> wrote at 01:22 this Wednesday (GMT):
Marc Haber wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On 64-bit systems (which is what most of us would be running by now),
You need to think beyond your desktop PC. Linux runs on billions of
embedded systems, many of them being a 32 bit architecture and bound
to stay there. Embedded systems tend to have an order of magnitude
more in lifetime. The year 2038 is already here for those systems.
So don't get in an elevator on Jan 18/19 2038?
Hopefully it's like Y2K where not too much happens
dl6--
I find it fascinating that Lawrence tries to argue with the guy who was actually there.
I first ran into the century problem in the early 1980's, in a COBOL program that dealt with rail stock for a Canadian railway company. Some of the cars have frames built in the 1800's. The wheel assemblies (truks) and couplers had been replaced multiple times, but the cars themselves were over 100 years old.
That was when I first started insisting on keeping 4 digit years in systems
I designed or was able to get altered.
On 18/04/2024 16:00, candycanearter07 wrote:
Woozy Song <suzyw0ng@outlook.com> wrote at 01:22 this Wednesday (GMT):A lot of legacy COBOL had to be fixed, just not linux
Marc Haber wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On 64-bit systems (which is what most of us would be running by now), >>>>You need to think beyond your desktop PC. Linux runs on billions of
embedded systems, many of them being a 32 bit architecture and bound
to stay there. Embedded systems tend to have an order of magnitude
more in lifetime. The year 2038 is already here for those systems.
So don't get in an elevator on Jan 18/19 2038?
Hopefully it's like Y2K where not too much happens
Back in the 1990ies people actually believed that the date
function returned the year modulo 100 and just slapped a 19 in front of
its output. Bad assumption, it actually returns the year MINUS 1900, so
it was at 100 in the year 2000 and it is at 124 now. So you need to ADD
1900 to get a valid year.
On Fri, 19 Apr 2024 07:29:48 +0200, Marc Haber wrote:
Back in the 1990ies people actually believed that the date
function returned the year modulo 100 and just slapped a 19 in front of
its output. Bad assumption, it actually returns the year MINUS 1900, so
it was at 100 in the year 2000 and it is at 124 now. So you need to ADD
1900 to get a valid year.
It had been documented to work that way many years before 2000--precisely
in anticipation of the problem, while trying to keep things backward- >compatible.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 19 Apr 2024 07:29:48 +0200, Marc Haber wrote:
Back in the 1990ies people actually believed that the date function
returned the year modulo 100 and just slapped a 19 in front of its
output. Bad assumption, it actually returns the year MINUS 1900, so it
was at 100 in the year 2000 and it is at 124 now. So you need to ADD
1900 to get a valid year.
It had been documented to work that way many years before
2000--precisely in anticipation of the problem, while trying to keep
things backward- compatible.
Of course it was documented as year-1900 from the very beginning. That
didnt keep software authors from silently assuming different.
On Thu, 18 Apr 2024 11:27:29 +0200, D wrote:
I find it fascinating that Lawrence tries to argue with the guy who was
actually there.
I have encountered way too many cases of customers not taking the simple, seemingly obvious precautions I mentioned, and then suffering the consequences years later.
Surely “prevention is better than cure” is just common sense.
On Fri, 19 Apr 2024 08:49:10 +0200, Marc Haber wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 19 Apr 2024 07:29:48 +0200, Marc Haber wrote:
Back in the 1990ies people actually believed that the date function
returned the year modulo 100 and just slapped a 19 in front of its
output. Bad assumption, it actually returns the year MINUS 1900, so it >>>> was at 100 in the year 2000 and it is at 124 now. So you need to ADD
1900 to get a valid year.
It had been documented to work that way many years before
2000--precisely in anticipation of the problem, while trying to keep >>>things backward- compatible.
Of course it was documented as year-1900 from the very beginning. That
didnt keep software authors from silently assuming different.
Only ones who didn’t read the docs.
You remind me of my business partner who was being pressed by a salesman
to take out 'key man ' insurance 'in case I died'.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Only ones who didn’t read the docs.
Some discussions will only die when everything has been told by
everybody.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 915 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 22:49:11 |
| Calls: | 12,168 |
| Files: | 186,520 |
| Messages: | 2,233,999 |