Message-ID: <62d49ce6@news.ausics.net> From: not@telling.you.invalid (Computer Nerd Kev) Subject: Re: Fwd: Linux on a small memory PC Newsgroups: comp.os.linux.misc References: <871quvs7m8.fsf@usenet.ankman.de> <87sfn8pr5t.fsf@usenet.ankman.de> <87zghai2dh.fsf@usenet.ankman.de> <16ydncnktcv0sE__nZ2dnUU7-Q3NnZ2d@earthlink.com> <62d34f66@news.ausics.net> <62d3c614@news.ausics.net> User-Agent: tin/2.0.1-20111224 ("Achenvoir") (UNIX) (Linux/2.4.31 (i586)) NNTP-Posting-Host: news.ausics.net Date: 18 Jul 2022 09:36:06 +1000 Organization: Ausics - https://www.ausics.net Lines: 58 X-Complaints: abuse@ausics.net Path: csiph.com!news.bbs.nz!news.ausics.net!not-for-mail Xref: csiph.com comp.os.linux.misc:35081 Dan Espen wrote: > Computer Nerd Kev writes: >> Dan Espen 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. -- __ __ #_ < |\| |< _#