On Sat, 16 Jul 2022 22:05:00 -0400, Dan Espen <dan1espen@gmail.com> wrote:
> I worked with computers from 1964 until a few years ago.
> I can't recall anyone abusing dates to save space.

On IBM mainframes, in COBOL programs there are two formats used for storing
decimal numbers. Zoned decimal and packed decimal. There are formats for
binary numbers too, but in finance programs they're rarely used.

With zoned decimal, each digit takes 1 byte. If there's a sign the + or - is
stored in a separate byte.

That wastes quite a bit of space, so most numbers are stored on disk using
packed decimal. Each half byte stores a decimal digit plus there's always
a half byte for the sign. x'C' for positive, x'D' for negative, x'F' for
unsigned.

One company I did some work for kept 6 digit dates stored in packed decimal,
but with the half byte for the sign removed so the date would fit in 3 bytes
instead of 4.

As this was a program originally written in the 70s, and had a very high
volume of records for the time, it probably saved them the equivalent of
a hard drive, every year.

That's the only company I ever did work for that did that. Until you figured
out what they were doing, it made using core dumps for debugging very difficult.

Regards, Dave Hodgins

On 7/16/22 2:24 AM, Charlie Gibbs wrote:
> On 2022-07-16, 25B.Z959 <25B.Z959@nada.net> wrote:
>
>> On 7/15/22 3:48 PM, Andreas Kohlbach wrote:
>>
>>> Yeah, machine rule should be in place by 3YK. The humankind can consider
>>> itself lucky do be able to. Might be better than the Skynet scenario.
>>
>> The trick to preventing SkyNet is two-fold ... first, and
>> this is the hardest, once we get near "human-level" AI there
>> must be rules to prevent SLAVERY - even though that's what
>> most people want, "robot slaves". Second, make an effort to
>> ensure said AI's and humans are mostly non-competitive for
>> limited resources - ie two different ecosystems.
>>
>> Once you make "people", you're responsible for their welfare.
>
> You're assuming we're responsible for the welfare of human beings,
> too. That doesn't seem to be working out too well.

Well, just don't be any LESS so in the case of the "AI"s
and you at least have an excuse :-)

>> To be most "generally useful" AIs will be made more and more
>> like humans in every respect. There comes a time, when you
>> simulate WELL enough, there's no longer a practical diff
>> between the sim and the original thing.
>
> There's one practical difference that nobody seems to be addressing.
> Who owns the hardware on which the AI is running? Are they not the
> AI's landlord? Given the abuses perpetrated on human tenants by
> human landlords (or property management firms, which aren't human),
> why should we think an AI's right to life, liberty, and the pursuit
> of happiness is any more secure than that of a human being? Can
> the AI be turned into a slave - or at least an indentured servant -
> by threats of homelessness? Consider that if said AI doesn't find
> a way to copy itself elsewhere, eviction - or simply pulling the
> plug on the computer on which it's running - is a death sentence.

Research the slavery debate, say circa 1858 ... you ARE
paraphrasing a lot of the slaveowners talking points.

In the end, the answer here cannot be properly "reasoned" -
you have to Just Know.

Sorry, but build de-facto "people" and you don't own them
anymore. Either don't build them or burn the pink slip and
eat the investment. That's my take.

"David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:

> On Sat, 16 Jul 2022 22:05:00 -0400, Dan Espen <dan1espen@gmail.com> wrote:
>> I worked with computers from 1964 until a few years ago.
>> I can't recall anyone abusing dates to save space.
>
> On IBM mainframes, in COBOL programs there are two formats used for storing
> decimal numbers. Zoned decimal and packed decimal. There are formats for
> binary numbers too, but in finance programs they're rarely used.
>
> With zoned decimal, each digit takes 1 byte. If there's a sign the + or - is
> stored in a separate byte.

Yeah, hardly saves any space at all.
Rarely, I've seen dates stored that way but the date is pretty much intact
assuming it was all numbers to begin with.

--
Dan Espen

On 7/16/22 8:48 AM, Dan Espen wrote:
> "25B.Z959" <25B.Z959@nada.net> writes:
>
>> On 7/15/22 3:48 PM, Andreas Kohlbach wrote:
>>> On Thu, 14 Jul 2022 20:16:57 -0400, 25B.Z959 wrote:
>>>>
>>>> On 7/10/22 5:57 PM, Andreas Kohlbach wrote:
>>>>> On Sun, 10 Jul 2022 00:45:42 -0400, 25B.Z959 wrote:
>>>>>>
>>>>>> Oh well, almost 80 years before we have THAT problem
>>>>>> again .....
>>>>> 2000 - 80 = 1920 ?
>>>>> 2038 - 80 = 1958 ?
>>>>> The Y2K38 problem sends clocks back about 137 years.
>>>>> I have no idea what you mean.
>>>>
>>>> I lost you there ....
>>> What were you referring to with "almost 80 years before"?
>>
>>
>> That's it's about 80 years until THIS decades 2-digit
>> dates become a problem ...
>>
>> Fortunately, few are so cheap to be using 2-digit dates
>> anymore. Not so in the past - they just assumed 19xx.
>> Saved a little space, easier calx.
>
> There you go, true to form. Now people use 2 digit dates because they
> are cheap.

You are neglecting Computers Past ..... low speed, low
capacity. You simplified calx, you squeezed-down the data
anywhere you could. I know, I had to do it.

So yes, they DID intentionally skimp.

> Hey, I'm writing dates in the US format mm/dd/yy. Why? Because the
> context makes it very clear what those 2 digits represent.

Until 'yy' doesn't mean "20yy" anymore.

> For data that covers shorter time spans, 2 digits is the way to go.
> Comparing 2 digit dates, knowing where we are in the current century is
> trivially easy.
>
> There are many cases where using 2 digit dates makes a lot of sense.
> It has nothing to do with anyone being cheap.

Human lifespans now fairly often exceed 100 years. There MAY
even be a very few alive now born in the 1800s. There WILL be
a great many in 2100 born in the 1900s. Not just people either,
laws, financial agreements, contracts etc..

So two-digits does NOT cover it.

Don't be cheap ... unix epoch at the very least. You can
skip the decimal points.

Hey, you can always use Roman numerals - you can easily
squeeze two standard ASCII chars into a single byte ...
even THREE bits if 000=I, 001=V, 010=L, 011=X, 100=C,
101=M and 110=negative. Easy to write a 'C' pgm using
odd-sized bit-fields so nothing's wasted :-)

I've done enough microcontroller programs ... you SQUEEZE !

Oops ... left out "D".

So, 000=I, 001=V, 010=X, 011=L, 100=C, 101=D, 110=M
and 111=negative ... ones, fives, tens, fifties,
hundreds, five-hundreds, thousands and 'minus'- all
bits used, beautiful packing :-)

Dan Espen <dan1espen@gmail.com> wrote:
> not@telling.you.invalid (Computer Nerd Kev) writes:
>>>> "25B.Z959" <25B.Z959@nada.net> writes:
>>>>> On 7/15/22 3:48 PM, Andreas Kohlbach wrote:
>>>>>> What were you referring to with "almost 80 years before"?
>>>>>
>>>>> That's it's about 80 years until THIS decades 2-digit
>>>>> dates become a problem ...
>>>>>
>>>>> Fortunately, few are so cheap to be using 2-digit dates
>>>>> anymore. Not so in the past - they just assumed 19xx.
>>>>> Saved a little space, easier calx.
>>>>
>> [snip]
>> By the way, I wonder whether anyone decided to store year data in
>> binary format as a signed 8-bit value where 0 = 1900? If so, some
>> software might find itself back in the 18th century come 2028.
>
> Signed 8 bit for years before 1900? Makes no sense. Unsigned 8 bit
> gets you pretty far. That doesn't sound like anything that would pass a
> design review.
>
> I worked with computers from 1964 until a few years ago.
> I can't recall anyone abusing dates to save space.

Isn't this exactly what the Y2K problem was all about? Storing the
last two digits as characters seems just as arbitrary as using a
single 8bit binary value. True with just one more byte, overflow
isn't a problem, but if everyone used just two more bytes and kept
all characters in a year, Y2K wouldn't have been a problem.

--
__ __
#_ < |\| |< _#

Computer Nerd Kev <not@telling.you.invalid> writes:

> Dan Espen <dan1espen@gmail.com> wrote:
>> not@telling.you.invalid (Computer Nerd Kev) writes:
>>>>> "25B.Z959" <25B.Z959@nada.net> writes:
>>>>>> On 7/15/22 3:48 PM, Andreas Kohlbach wrote:
>>>>>>> What were you referring to with "almost 80 years before"?
>>>>>>
>>>>>> That's it's about 80 years until THIS decades 2-digit
>>>>>> dates become a problem ...
>>>>>>
>>>>>> Fortunately, few are so cheap to be using 2-digit dates
>>>>>> anymore. Not so in the past - they just assumed 19xx.
>>>>>> Saved a little space, easier calx.
>>>>>
>>> [snip]
>>> By the way, I wonder whether anyone decided to store year data in
>>> binary format as a signed 8-bit value where 0 = 1900? If so, some
>>> software might find itself back in the 18th century come 2028.
>>
>> Signed 8 bit for years before 1900? Makes no sense. Unsigned 8 bit
>> gets you pretty far. That doesn't sound like anything that would pass a
>> design review.
>>
>> I worked with computers from 1964 until a few years ago.
>> I can't recall anyone abusing dates to save space.
>
> Isn't this exactly what the Y2K problem was all about? Storing the
> last two digits as characters seems just as arbitrary as using a
> single 8bit binary value. True with just one more byte, overflow
> isn't a problem, but if everyone used just two more bytes and kept
> all characters in a year, Y2K wouldn't have been a problem.

The user enters that 2 digit year. If you want to store a 4 digit year,
some piece of software is going to have to figure out whether to add
'19' or '20'.

When you want to enter a credit card expiration year, no one has the
patience to enter 20xx for the next 100 years.

I did a lot of Y2K remediation. Rarely was the correct solution to ask
the user to enter a 4 digit year. I can't recall that ever happening.

Anyway, why replace the Y2K problem with the Y10K problem when a sliding
window makes the problem go away forever?

--
Dan Espen

On 2022-07-16, Computer Nerd Kev <not@telling.you.invalid> wrote:

> By the way, I wonder whether anyone decided to store year data in
> binary format as a signed 8-bit value where 0 = 1900? If so, some
> software might find itself back in the 18th century come 2028.

MS-DOS stores file dates in a 16-bit field, allocating 7 bits for
year, 4 bits for month, and 5 bits for day. The year counts from
1980, giving it a Y2108 problem.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On 2022-07-17, 25B.Z959 <25B.Z959@nada.net> wrote:

> On 7/16/22 8:48 AM, Dan Espen wrote:
>
>> "25B.Z959" <25B.Z959@nada.net> writes:
>>
>>> Fortunately, few are so cheap to be using 2-digit dates
>>> anymore. Not so in the past - they just assumed 19xx.
>>> Saved a little space, easier calx.
>>
>> There you go, true to form. Now people use 2 digit dates because
>> they are cheap.
>
> You are neglecting Computers Past ..... low speed, low
> capacity. You simplified calx, you squeezed-down the data
> anywhere you could. I know, I had to do it.

Me too. My first job was in an all-card shop. To squeeze things
onto an 80-column card, we stored dates in 5 columns as ddmmy.
That's right, we only kept the last digit of the year. I started
there in 1970, and one of my first assignments was to go through
all report programs and change the '6' they inserted in front of
the year to '7'.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On Sun, 17 Jul 2022 04:19:32 -0400, Computer Nerd Kev <not@telling.you.invalid> wrote:
> Isn't this exactly what the Y2K problem was all about? Storing the
> last two digits as characters seems just as arbitrary as using a
> single 8bit binary value. True with just one more byte, overflow
> isn't a problem, but if everyone used just two more bytes and kept
> all characters in a year, Y2K wouldn't have been a problem.

The first time I encountered problems with 2 digit years was in the 1980's. The
equipment inventory included equipment originally built in the 1880s.

Regards, Dave Hodgins

with <tavqoc$3jit6$1@dont-email.me> Dan Espen wrote:
> not@telling.you.invalid (Computer Nerd Kev) writes:
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>> On 2022-07-16, Dan Espen <dan1espen@gmail.com> wrote:
>>>> "25B.Z959" <25B.Z959@nada.net> writes:
>>>>> On 7/15/22 3:48 PM, Andreas Kohlbach wrote:

*SKIP*
>> By the way, I wonder whether anyone decided to store year data in
>> binary format as a signed 8-bit value where 0 = 1900? If so, some
>> software might find itself back in the 18th century come 2028.
> Signed 8 bit for years before 1900? Makes no sense. Unsigned 8 bit
> gets you pretty far. That doesn't sound like anything that would pass
> a design review.
> I worked with computers from 1964 until a few years ago. I can't
> recall anyone abusing dates to save space.

FAT only recognizes even numbers for seconds. If this doesn't
constitutes abuse then I wonder what a sterile world you've lived in all
that time.

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:

> On 2022-07-17, 25B.Z959 <25B.Z959@nada.net> wrote:
>
>> On 7/16/22 8:48 AM, Dan Espen wrote:
>>
>>> "25B.Z959" <25B.Z959@nada.net> writes:
>>>
>>>> Fortunately, few are so cheap to be using 2-digit dates
>>>> anymore. Not so in the past - they just assumed 19xx. Saved a
>>>> little space, easier calx.
>>>
>>> There you go, true to form. Now people use 2 digit dates because
>>> they are cheap.
>>
>> You are neglecting Computers Past ..... low speed, low
>> capacity. You simplified calx, you squeezed-down the data anywhere
>> you could. I know, I had to do it.
>
> Me too. My first job was in an all-card shop. To squeeze things onto
> an 80-column card, we stored dates in 5 columns as ddmmy. That's
> right, we only kept the last digit of the year. I started there in
> 1970, and one of my first assignments was to go through all report
> programs and change the '6' they inserted in front of the year to '7'.

In an all card shop having more than 1 card for a logical record is a
problem. Not insurmountable but difficult. I've heard the one digit
year story in that context but never had to deal with it.

Clearly a case of the employer being cheap because he didn't use
larger cards.

--
Dan Espen

Eric Pozharski <whynot@pozharski.name> writes:

> with <tavqoc$3jit6$1@dont-email.me> Dan Espen wrote:
>> not@telling.you.invalid (Computer Nerd Kev) writes:
>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>>> On 2022-07-16, Dan Espen <dan1espen@gmail.com> wrote:
>>>>> "25B.Z959" <25B.Z959@nada.net> writes:
>>>>>> On 7/15/22 3:48 PM, Andreas Kohlbach wrote:
>
> *SKIP*
>>> By the way, I wonder whether anyone decided to store year data in
>>> binary format as a signed 8-bit value where 0 = 1900? If so, some
>>> software might find itself back in the 18th century come 2028.
>> Signed 8 bit for years before 1900? Makes no sense. Unsigned 8 bit
>> gets you pretty far. That doesn't sound like anything that would pass
>> a design review.
>> I worked with computers from 1964 until a few years ago. I can't
>> recall anyone abusing dates to save space.
>
> FAT only recognizes even numbers for seconds. If this doesn't
> constitutes abuse then I wonder what a sterile world you've lived in all
> that time.

Certainly not the MS DOS world.

Here's what Wikipedia says:

2 seconds for last modified time,
10 ms for creation time,
1 day for access date,
2 seconds for deletion time

It's MSFT, doesn't surprise me in the least.
Of course these aren't user entered dates which are the dates I was
thinking of. I mostly worked IBM mainframes, I wouldn't be surprised if
their system software isn't full of date abuse.

--
Dan Espen

On Sun, 17 Jul 2022 13:57:36 -0400, Dan Espen <dan1espen@gmail.com> wrote:
> Clearly a case of the employer being cheap because he didn't use
> larger cards.

Hollerith (IBM) Punch cards were 80 columns. The limit is imposed by both the
card punch machines and the card readers.

Regards, Dave Hodgins

"David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:

> On Sun, 17 Jul 2022 13:57:36 -0400, Dan Espen <dan1espen@gmail.com> wrote:
>> Clearly a case of the employer being cheap because he didn't use
>> larger cards.
>
> Hollerith (IBM) Punch cards were 80 columns. The limit is imposed by both the
> card punch machines and the card readers.
>
> Regards, Dave Hodgins

I previously mentioned that I became a computer programmer in 1964.

--
Dan Espen

On Sun, 17 Jul 2022 15:00:05 -0400, Dan Espen <dan1espen@gmail.com> wrote:
> I previously mentioned that I became a computer programmer in 1964.

Ten years sooner than me. :-)

Regards, Dave Hodgins

On Sun, 17 Jul 2022 00:57:31 -0000 (UTC), Tom Furie wrote:
>
> On 2022-07-17, Computer Nerd Kev <not@telling.you.invalid> wrote:
>> Computer Nerd Kev <not@telling.you.invalid> wrote:
>>> By the way, I wonder whether anyone decided to store year data in binary
>>> format as a signed 8-bit value where 0 = 1900? If so, some software might
>>> find itself back in the 18th century come 2028.
>>
>> Oh, err 20th century actually (-0 = 1900).
>
> You were right the first time - 1772, to be precise. Signed 8-bit ticks over
> from +127 to -128.

8-bit would have saved the world. Why did I only sell my Commodore 64? ;-)
--
Andreas

On 17 Jul 2022 09:53:10 +1000, Computer Nerd Kev wrote:
>
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>
>> there's that age-old doubt as to whether 07/12/22 means July 12
>> or December 7.
>
> Oh yes. Even locally-bought digital clocks/watches tend to show
> dates in US format. When you get such a thing the first task is to
> cycle through all the numbers to see whether the first one resets
> at 12 or not.

Mine was so cheap it lacks segments in the left most "digit". It can only
present a "2" or is off. Another dot indicates AM or PM. Also the package
said something like "Modern 12h AM/PM clock". *LOL*

A missing the 24 hour format I was used to in Europe.

Some date formats are confusing here too. Sometimes a web form says it
wants

.../../..

and Another

...-..-..

I guess the first is meant to mm/dd/yy and the latter dd-mm-yow.
--
Andreas

On Sun, 17 Jul 2022 11:16:25 -0400, Dan Espen wrote:
>
> Computer Nerd Kev <not@telling.you.invalid> writes:
>
>> Dan Espen <dan1espen@gmail.com> wrote:
>>> not@telling.you.invalid (Computer Nerd Kev) writes:
>>>
>>> Signed 8 bit for years before 1900? Makes no sense. Unsigned 8 bit
>>> gets you pretty far. That doesn't sound like anything that would pass a
>>> design review.
>>>
>>> I worked with computers from 1964 until a few years ago.
>>> I can't recall anyone abusing dates to save space.
>>
>> Isn't this exactly what the Y2K problem was all about? Storing the
>> last two digits as characters seems just as arbitrary as using a
>> single 8bit binary value. True with just one more byte, overflow
>> isn't a problem, but if everyone used just two more bytes and kept
>> all characters in a year, Y2K wouldn't have been a problem.
>
> The user enters that 2 digit year. If you want to store a 4 digit year,
> some piece of software is going to have to figure out whether to add
> '19' or '20'.

If the software allows 20XX... If not (and it's older) it might only
store two digits: possible Y2K impact.

> When you want to enter a credit card expiration year, no one has the
> patience to enter 20xx for the next 100 years.

I see that in web form pulldown menus are used giving the current and may
be 10 next years (like 2030) to just click.

> I did a lot of Y2K remediation. Rarely was the correct solution to ask
> the user to enter a 4 digit year. I can't recall that ever happening.

Or it was static. So the 19 was fixed (and not saved) and the user added
the rest. So when 1985 he just typed "85" and the machine would likely
also only store "85".

I move this into the folklore group, knowing many of you read there too.
--
Andreas

On 2022-07-17, Eric Pozharski <whynot@pozharski.name> wrote:

> with <tavqoc$3jit6$1@dont-email.me> Dan Espen wrote:
>
>> not@telling.you.invalid (Computer Nerd Kev) writes:
>>
>>> By the way, I wonder whether anyone decided to store year data in
>>> binary format as a signed 8-bit value where 0 = 1900? If so, some
>>> software might find itself back in the 18th century come 2028.
>>
>> Signed 8 bit for years before 1900? Makes no sense. Unsigned 8 bit
>> gets you pretty far. That doesn't sound like anything that would pass
>> a design review.
>> I worked with computers from 1964 until a few years ago. I can't
>> recall anyone abusing dates to save space.
>
> FAT only recognizes even numbers for seconds. If this doesn't
> constitutes abuse then I wonder what a sterile world you've lived in
> all that time.

Moving source files back and forth between MS-DOS and *n*x systems
plays hell with makefiles.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On 2022-07-17, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

> On Sun, 17 Jul 2022 04:19:32 -0400, Computer Nerd Kev
> <not@telling.you.invalid> wrote:
>
>> Isn't this exactly what the Y2K problem was all about? Storing the
>> last two digits as characters seems just as arbitrary as using a
>> single 8bit binary value. True with just one more byte, overflow
>> isn't a problem, but if everyone used just two more bytes and kept
>> all characters in a year, Y2K wouldn't have been a problem.
>
> The first time I encountered problems with 2 digit years was in the 1980's.
> The equipment inventory included equipment originally built in the 1880s.

The mortgage programs I worked on in the 1980s needed 4-digit years
because a 20-year amortization put them into the 21st century.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On 2022-07-17, Andreas Kohlbach <ank@spamfence.net> wrote:

> On 17 Jul 2022 09:53:10 +1000, Computer Nerd Kev wrote:
>
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>
>>> there's that age-old doubt as to whether 07/12/22 means July 12
>>> or December 7.
>>
>> Oh yes. Even locally-bought digital clocks/watches tend to show
>> dates in US format. When you get such a thing the first task is to
>> cycle through all the numbers to see whether the first one resets
>> at 12 or not.
>
> Mine was so cheap it lacks segments in the left most "digit". It can only
> present a "2" or is off.

I've heard that described in the electronics catalogs as (e.g.) a
"3 1/2 digit display". The "half digit" refers to a high-order
position which can only display a 1.

> Another dot indicates AM or PM. Also the package
> said something like "Modern 12h AM/PM clock". *LOL*
>
> A missing the 24 hour format I was used to in Europe.
>
> Some date formats are confusing here too. Sometimes a web form says it
> wants
>
> ../../..
>
> and Another
>
> ..-..-..
>
> I guess the first is meant to mm/dd/yy and the latter dd-mm-yow.

Web forms are notoriously inconsistent. When taking a credit card
number, some insist that you leave no spaces between groups of digits,
while others don't care. Ditto for postal codes. It seems downright
unfriendly; I wrote better code than that back before we had CPU cycles
to burn.

As for date formats, I used year/month/day before switching to ISO 8601;
now I use year-month-day.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

[Cross-posted to alt.folklore.computers]

On 2022-07-17, Dan Espen <dan1espen@gmail.com> wrote:

> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>
>> On 2022-07-17, 25B.Z959 <25B.Z959@nada.net> wrote:
>>
>>> On 7/16/22 8:48 AM, Dan Espen wrote:
>>>
>>>> "25B.Z959" <25B.Z959@nada.net> writes:
>>>>
>>>>> Fortunately, few are so cheap to be using 2-digit dates
>>>>> anymore. Not so in the past - they just assumed 19xx. Saved a
>>>>> little space, easier calx.
>>>>
>>>> There you go, true to form. Now people use 2 digit dates because
>>>> they are cheap.
>>>
>>> You are neglecting Computers Past ..... low speed, low
>>> capacity. You simplified calx, you squeezed-down the data anywhere
>>> you could. I know, I had to do it.
>>
>> Me too. My first job was in an all-card shop. To squeeze things onto
>> an 80-column card, we stored dates in 5 columns as ddmmy. That's
>> right, we only kept the last digit of the year. I started there in
>> 1970, and one of my first assignments was to go through all report
>> programs and change the '6' they inserted in front of the year to '7'.
>
> In an all card shop having more than 1 card for a logical record is a
> problem. Not insurmountable but difficult. I've heard the one digit
> year story in that context but never had to deal with it.

We used two cards for customer name data, but they didn't have dates
in them, just long names. You're right, having more than one card
for a logical record is a pain in the ass. I use the present tense
because I'm still faced with such files today.

For aged accounts receivables, we needed half a dozen cost fields.
To accomodate this, we punched the packed decimal fields into the
cards without unpacking them. The decks were noticeably flimsier
than a normal deck, thanks to all those 12-0-1-8-9 punches.

> Clearly a case of the employer being cheap because he didn't use
> larger cards.

:-)

There were always those Remington-Rand 90-column cards...

Maybe that's why IBM came up with 96-column cards on the
System/3. They wouldn't do it to be incompatible, would
they? Nah...

Fun fact: 96-column cards are exactly as long as 80-column cards
are wide. That probably simplified things for factories that
made both..

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

Andreas Kohlbach <ank@spamfence.net> wrote:
> On Sun, 17 Jul 2022 11:16:25 -0400, Dan Espen wrote:
>>
>> Computer Nerd Kev <not@telling.you.invalid> writes:
>>
>>> Dan Espen <dan1espen@gmail.com> wrote:
>>>> not@telling.you.invalid (Computer Nerd Kev) writes:
>>>>
>>>> Signed 8 bit for years before 1900? Makes no sense. Unsigned 8 bit
>>>> gets you pretty far. That doesn't sound like anything that would pass a
>>>> design review.
>>>>
>>>> I worked with computers from 1964 until a few years ago.
>>>> I can't recall anyone abusing dates to save space.
>>>
>>> Isn't this exactly what the Y2K problem was all about? Storing the
>>> last two digits as characters seems just as arbitrary as using a
>>> single 8bit binary value. True with just one more byte, overflow
>>> isn't a problem, but if everyone used just two more bytes and kept
>>> all characters in a year, Y2K wouldn't have been a problem.
>>
>> The user enters that 2 digit year. If you want to store a 4 digit year,
>> some piece of software is going to have to figure out whether to add
>> '19' or '20'.
>
> If the software allows 20XX... If not (and it's older) it might only
> store two digits: possible Y2K impact.
>
>> When you want to enter a credit card expiration year, no one has the
>> patience to enter 20xx for the next 100 years.
>
> I see that in web form pulldown menus are used giving the current and may
> be 10 next years (like 2030) to just click.
>
>> I did a lot of Y2K remediation. Rarely was the correct solution to ask
>> the user to enter a 4 digit year. I can't recall that ever happening.
>
> Or it was static. So the 19 was fixed (and not saved) and the user added
> the rest. So when 1985 he just typed "85" and the machine would likely
> also only store "85".
>
> I move this into the folklore group, knowing many of you read there too.

What’s often done is to pick a base year older than the oldest date you
have to deal with. For example, if your company was started in 1970 you
can’t have order dates prior to that, so you can interpret order dates ‘00’
to ‘69’ as 2000 to 2069, and anything ‘70’ and above as 1970. This is only
a temporary kludge, but in this case it will work until 2070, by which time
global warming will have killed us all off.

--
Pete

Dan Espen <dan1espen@gmail.com> wrote:
> Computer Nerd Kev <not@telling.you.invalid> writes:
>> Dan Espen <dan1espen@gmail.com> wrote:
>>> not@telling.you.invalid (Computer Nerd Kev) writes:
>>>>>> "25B.Z959" <25B.Z959@nada.net> writes:
>>>>>>> On 7/15/22 3:48 PM, Andreas Kohlbach wrote:
>>>>>>>> What were you referring to with "almost 80 years before"?
>>>>>>>
>>>>>>> That's it's about 80 years until THIS decades 2-digit
>>>>>>> dates become a problem ...
>>>>>>>
>>>>>>> Fortunately, few are so cheap to be using 2-digit dates
>>>>>>> anymore. Not so in the past - they just assumed 19xx.
>>>>>>> Saved a little space, easier calx.
>>>>>>
>>>> [snip]
>>>> By the way, I wonder whether anyone decided to store year data in
>>>> binary format as a signed 8-bit value where 0 = 1900? If so, some
>>>> software might find itself back in the 18th century come 2028.
>>>
>>> Signed 8 bit for years before 1900? Makes no sense. Unsigned 8 bit
>>> gets you pretty far. That doesn't sound like anything that would pass a
>>> design review.
>>>
>>> I worked with computers from 1964 until a few years ago.
>>> I can't recall anyone abusing dates to save space.
>>
>> Isn't this exactly what the Y2K problem was all about? Storing the
>> last two digits as characters seems just as arbitrary as using a
>> single 8bit binary value. True with just one more byte, overflow
>> isn't a problem, but if everyone used just two more bytes and kept
>> all characters in a year, Y2K wouldn't have been a problem.
>
> The user enters that 2 digit year. If you want to store a 4 digit year,
> some piece of software is going to have to figure out whether to add
> '19' or '20'.

If that computer has some way of obtaining the current date in
complete form, the software should be smart enough to figure out
those first two characters by itself. Failing that (eg. very old or
embedded devices), it could of course be configurable.

This is completely separate from the issue of storing dates, which
as I originally proposed could even be done in a binary number
offset from some arbitrary point, and that user would never have
any idea of the fact.

> Anyway, why replace the Y2K problem with the Y10K problem when a sliding
> window makes the problem go away forever?

That only makes sense in some contexts. What if you're trying to
store historical weather records that started in the 1800s, for
example? You don't want to throw them all away when your window
moves.

--
__ __
#_ < |\| |< _#