Stop using B.C.E. and C.E. you cretins!

I do get that it would require a big change regarding computer programs, GPS systems and the like. But still, you can make a change once and push it through the system electronically via updates.

Oh. I would be thrilled if the world of legacyware programming worked that way. Thrilled.

Well, actually not so thrilled since I would be out of a job.
 
I do get that it would require a big change regarding computer programs, GPS systems and the like. But still, you can make a change once and push it through the system electronically via updates. You couldn't do that in the 18th century.

Any sane computer program is internally using another system anyway. The usual calendar is only used for the user interface. So the necessary adjustments shouldn't be that big.
 
Any sane computer program is internally using another system anyway. The usual calendar is only used for the user interface. So the necessary adjustments shouldn't be that big.

Leifmk seems to think it is a big change.
 
I don't mind a dating system that refer to Jesus.

I mind having a dating system that refer to him as "The Lord".

BC (Before Christ) = Fine.
AD (Anno Domini, Year of the Lord) = Not Fine.
 
Canada was first forcing teachers to use the new using B.C.E. and C.E. while I was in school so those are the ones I am used too.

They make sense because anyone regardless if they are christian or not can use them.
 
Either way I don't really care. I'm now more used to CE and BCE, anyways, but I sometimes use AD and BC. It just really doesn't matter to me. If more and more people use CE and BCE in the coming years, cool; if more and more people use AD and BC in the coming years, also cool.

Calendars are funny things.
 
Any sane computer program is internally using another system anyway. The usual calendar is only used for the user interface. So the necessary adjustments shouldn't be that big.

Even if this statement is correct, it assumes that most of those legacy systems are "sane".

I know that that is a wrong assumption to make in the business world. Far too many of them were cobbled together over decades as needs and technologies changed creating a terrible mess.
Then you have issues where they were developed on the cheap often with the requirements changing on a near daily basis until it was released.
 
Even if this statement is correct, it assumes that most of those legacy systems are "sane".

I know that that is a wrong assumption to make in the business world. Far too many of them were cobbled together over decades as needs and technologies changed creating a terrible mess.
Then you have issues where they were developed on the cheap often with the requirements changing on a near daily basis until it was released.
Interesting aside:
I visited an Ameren Missouri power distribution control center and they were still using a mainframe that had been continuously running since the 60's as it ran the only operating system that had never crashed on them.
 
Old school is the best school!
Anything from 68 or before is suspect IMO.;)
Even if this statement is correct, it assumes that most of those legacy systems are "sane".

I know that that is a wrong assumption to make in the business world. Far too many of them were cobbled together over decades as needs and technologies changed creating a terrible mess.
Then you have issues where they were developed on the cheap often with the requirements changing on a near daily basis until it was released.

I would like to say though that by the time we need or want a new calendar system (after say, interplanetary colonization renders an earth-centric year obsolete) we probably won't have to worry about how difficult reprogramming calendar systems into our computer systems are. I'm sure it will be trivial by then.
 
OP wants Y2K to happen all over again.
 
Interesting aside:
I visited an Ameren Missouri power distribution control center and they were still using a mainframe that had been continuously running since the 60's as it ran the only operating system that had never crashed on them.

I have heard of people who work full-time keeping indispensable legacy code running. Not maintaining the legacy code itself (that is simple and common; it is what I do in my job), but maintaining the emulation layer which allows their antique legacy code to run on modern systems (because the machines it originally ran on have not existed for decades and have no surviving descendants). You cannot get rid of legacy code.
 
I have heard of people who work full-time keeping indispensable legacy code running. Not maintaining the legacy code itself (that is simple and common; it is what I do in my job), but maintaining the emulation layer which allows their antique legacy code to run on modern systems (because the machines it originally ran on have not existed for decades and have no surviving descendants). You cannot get rid of legacy code.

Actually, the machine it was on was very old, an actual mainframe. Couldn't tell you if it's not original.

And you can get rid of legacy code. Get new systems with new code to completely replace the old. I'm not saying that's always practical, necessary or even wanted. But your statement is an absolute, which are generally false.
 
I think this is one of those silly things like calling Christmas Break "Winter" break, but I'm pretty apathetic about it.
 
And you can get rid of legacy code. Get new systems with new code to completely replace the old. I'm not saying that's always practical, necessary or even wanted. But your statement is an absolute, which are generally false.

You're right, in so far as you CAN get rid of legacy code if you can persuade the people in charge of the budget to pay for what it takes. In most actual cases this is usually somewhere between almost impossible and completely impossible.
 
Back
Top Bottom