Millennium bug or centennial bug?   Are we not just going round again? - Page 1
Forum section: electronics / general

author: paulca
author_rank: Super Contributor
timestamp: November 15, 2024, 10:52:22 am
content: Was working on a print form from an application and the customer wants the following to capture a date.This _____ day of _____ 20___So, the form is voluntarily accepting a future obsolescence and centennial bug, just to save the user from writing two digits.How many of you still use hardware clock chips which still to this day only support 2 digits for the year?I know some of the programming language "fixes" were, not fixes at all, but hacks. (Perl 2024 = 124)When it was the 60s, 70s, 80s, people thought "It will be all fixed and completely different by then, so we don't care."Well, it's now the 20s. When exactly do we start thinking adult on this?

author: Nominal Animal
author_rank: Super Contributor
timestamp: November 15, 2024, 11:51:44 am
content: We have ISO 8601 (yyyy-mm-ddTHH:MM:SS.sss±hh:mm), which is unambiguous and sorts correctly, supports arbitrary time zones and offsets, and works for the next eight thousand years or so.What you cannot fix is humans.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 15, 2024, 09:18:36 pm
content: I use ISO 8601 for dates whenever possible.But yes, many hardware RTCs still have various limitations regarding the year. Now those chips must IMO be seen as temporary date/time handling anyway, and any "long-term" storage of date information should at least follow ISO 8601.

author: TimFox
author_rank: Super Contributor
timestamp: November 15, 2024, 09:27:40 pm
content: When I was a child in elementary school many decades ago, the school system actually had paper forms that asked for the year in the format "195__".Even at age 8, I thought that was stupid.

author: vk6zgo
author_rank: Super Contributor
timestamp: November 16, 2024, 05:07:17 am
content: Quote from: TimFox on November 15, 2024, 09:27:40 pmI remember ones that said "193___".Printing must have been very cheap in the 1930s, or they thought they would go through a lot in that decade.Why it couldn't have been just "19____" is beyond me.What didn't help withe the "Y2K" stuff was the assumption that everything would just stop working, aircraft would fall out of the sky, the power grid would crash & so on.Anybody with any experience of the world would have known that wouldn't happen, but the panicky stuff appeared all over the media.

author: wilfred
author_rank: Super Contributor
timestamp: November 16, 2024, 08:55:13 am
content: Quote from: vk6zgo on November 16, 2024, 05:07:17 amI worked at a big Australian telco and they set up duplicate IT systems and ran cross checks against recent transactions and databases as they checked application code and updated all the systems software and yeah it turned out to be a complete fizzer and a monumental waste of time. But the overtime pay helped me save for a home.

author: 5U4GB
author_rank: Super Contributor
timestamp: November 16, 2024, 09:25:32 am
content: Quote from: TimFox on November 15, 2024, 09:27:40 pmI've seen a memorial plaque that commemorated the fallen from the '71 conflict.Hint: It predated computers, punched cards, and everything similar.

author: paulca
author_rank: Super Contributor
timestamp: November 16, 2024, 11:21:50 am
content: Quote from: vk6zgo on November 16, 2024, 05:07:17 amThe media overhyped it yes. However there was a LOT of stuff that wasn't going to work. If we had done nothing it would have been chaos.There was also a great amount of profiteering. Electrical test engineers even got in on it.

author: paulca
author_rank: Super Contributor
timestamp: November 16, 2024, 11:24:25 am
content: Quote from: SiliconWizard on November 15, 2024, 09:18:36 pmBut.. ISO8601 is "human interface" format. Date and datetimes are not stored that way. I mean, yes, I have seen people saving dates into DBs as Strings, but unless that database has a funky concept of time (some do) it's probably because they never needed to process it again.The most common format of storage is epoch will millis or epoc with micros.

author: vk6zgo
author_rank: Super Contributor
timestamp: November 16, 2024, 12:04:43 pm
content: Quote from: paulca on November 16, 2024, 11:21:50 am"Paperwork", yes, but actual large pieces of engineering operate on elapsed time, not calendar dates, so bills might not have been sent out or paid, & so on, but all the things that the "panic merchants" got stirred up about not only didn't happen, they could not have happened.I, personally, blame the film & TV industry for the ridiculous ideas people have.It makes a great story line to have a power grid all operated by a computer that can be hacked, causing all sorts of cascading failures, but in reality, there are many places where manual intervention is possible, & probably routine.Another favourite is that one where somebody "hacks" a city's underground railway system, & there is an "out of control train" careering around that only the protagonist can stop.The existence of main circuit breakers is ignored, & the motive power of the train is regarded almost as something that just appears "out of the air".Many of the public have little knowledge of engineering or the natural world, & it is only a small step from there to believing forest fires are started by "space lasers" or Hurricanes by "weather weapons".

author: jc101
author_rank: Frequent Contributor
timestamp: November 16, 2024, 09:13:57 pm
content: I was working within the Blue Light services over the millennium, and there would some nasties found. Some would have taken out safety of life call handing software and even parts of the radio system at the time. We found them all beforehand. One bit of critical national infrastructure had a backup system fall over. It took a little while to get sorted but had no public impact. Otherwise it was a quiet night.Also found someone in the Home Office was flogging some checking software that wasn't theirs. I was asked to see how to install it automatically on the PC (computer, not bobbies) estate. We were told this was approved software and should be used for testing. Was suspicious when I dug into it. He got done for fraud with a few years inside as a result. Fun times!

author: TimFox
author_rank: Super Contributor
timestamp: November 16, 2024, 09:19:17 pm
content: Before I retired, I had custody of an old computer (I believe it ran Windows 3.1) that was only kept due to some obsolete drafting software, where occasionally someone needed to open a drawing file.Early on New Year's Day 2000, I emerged from a night club and saw that the city streetlights were still working, so I went home.However, when I returned to work, that old computer showed a strange date (AD 100 or something).Of course, the 21st Century and 3rd Millenium did not start until a year later, on January 1, 2001.

author: 5U4GB
author_rank: Super Contributor
timestamp: November 17, 2024, 06:59:31 am
content: I once worked with a Multician who, like many other Multicians, liked to tell people that "Multics did all that decades ago". At some point one of the folks went through the Multics code and had a look at the date-handling code, which (a) was written by said individual and (b) wasn't Y2K safe. He wasn't amused when we teased him about this being another example of Multics doing it all decades ago.

author: tom66
author_rank: Super Contributor
timestamp: November 17, 2024, 02:00:39 pm
content: GPS has a 'stupid' bug where the week counter is only 10-bit wide, 0-1023 weeks, so it wraps around every 19 years. It is therefore impossible, without other satellite system data or an external time, to unambiguously determine GPS date after a device is more than 19 years old.

author: PlainName
author_rank: Super Contributor
timestamp: November 17, 2024, 10:54:35 pm
content: QuoteDon't see the problem. In 75 years time they can just change the 0 to a 1 and continue, meanwhile it's that little bit simpler for the user. It's not like code that can't be changed because it's embedded in something.If you think that's a problem and ease of use for whoever is filling it in isn't worth it, why have the "This ___ day of ___" and all that at all? Just let them write the entire thing out longhand. It's not that half the date is filled out already as such, it's that it's placed so the form filler doesn't have to wonder where to write the stuff, or what format (words, numbers, American format or proper, etc).

author: Siwastaja
author_rank: Super Contributor
timestamp: November 18, 2024, 08:27:13 am
content: Quote from: tom66 on November 17, 2024, 02:00:39 pmThis week counter rolling over is being ridiculed every now and then, but rarely anyone questions theexistenceof week counter, just the width of it. It is hard to understand to me why you would have a week counter in the first place. Normal sensible human beings use epoch time (or similar, doesn't need to be 1970-based) for internal representation and low-level binary interfaces, and convert it to whatever representation is needed. Week specifically is a weird construct. I understandyearanddayas concepts because these are related to naturally occurring planetary cycles and therefore could be relevant for GPS (I don't know), butweekmost definitely isn't.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 18, 2024, 09:02:46 am
content: Quote from: paulca on November 16, 2024, 11:24:25 amIt's not just about what is being "displayed", which is one thing, but about what data is actually held, which ISO 8601 defines unambiguously. From there, you can handle this data in the way you see fit for a particular internals of a particular applications. For instance, it defines the year with a *minimum* mandated of 4 digits. Note that it's a minimum. After that, if you need to convey this date to humans in a readable form, yes it's also recommended to use the format that they specify. But nobody forces you to store it as a string.Quote from: paulca on November 16, 2024, 11:24:25 amI don't know about that being the "most common", that's a wild statement without context. It's common on Unix-like systems. Outside of that, you'll find anything and its brothers.Unix epochs are not the panacea. They are defined to originate in 1970, which prevents you from using that for earlier dates (you could always define your own origin, but then forget about any standard, that'll be purely proprietary, if that's your thing). If used for only dating present and future dates, that's ok. But the worst part, of course, is that they are prone to the very same problem if used only on 32 bits. They end in 2038. Wanna get back in circles? You can always use 64-bit epochs (which all decently recent systems will use) to alleviate that. One downside, if again the date origin is not a problem, is that it needs a back and from conversion that is not completely trivial to implement and may take excessive space on a small microcontroller, for instance. If conversion is needed there.Also, if you actually store the data as defined in ISO 8601 in binary form (compressed for the required number of bits), you should end up with slightly fewer than the 8 bytes required for a 64-bit epoch.So many ways to skin a cat.As to RTCs, most are precisely designed to make things easier (no conversion needed), which is why they also usually store everything in BCD. This convenience may be a bit anachronic these days, with CPUs and MCUs much more powerful than they were 30 years ago or more. The fact most only store years on 2 digits, though, is becoming inexcusable. Saving a 2 x 4-bit register, really?

author: Siwastaja
author_rank: Super Contributor
timestamp: November 18, 2024, 10:28:54 am
content: Quote from: SiliconWizard on November 18, 2024, 09:02:46 amI'm surprised you are getting such fundamentals wrong. Just like using Celsius where the origin is chosen (arbitrarily) at the freezing point of water does not prevent expressing temperatures below that, Unix epoch does not prevent presenting dates before 1970. They are represented simply with negative numbers, you don't need to define your own proprietary origin for that.Also the range is not from 1970 to 2038. U32 representation gives the former limit, I32 the latter. With U32 and limit in 1970, it goes much further in future than 2038.None in the epoch concept itself limits the representation to 32 bits. And in any case, switching from 32-bit to 64-bit representation is colossally easier than trying to redesign more bits into some freaking week number of something, underlining the advantages of the epoch systems and their simplicity.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 18, 2024, 10:56:05 am
content: Quote from: SiliconWizard on November 18, 2024, 09:02:46 amRTCs are designed the way they are for applications that do not use time for any sort of calculations; just direct interaction with the human being. This design choice offloads part of the complexityto the userand partially does it itself.RTC which just simply increments its second counter which then ripples over to minutes counter and so on up to years counter has one fundamental problem: it does not keep time correctly. After implementing the days_per_month[] in silicon, the most obvious remaining issue is with leap years. So RTC designers then have to implement extra logic to handle leap years (and some would get it wrong, of course). Now, itstilldoes not keep time correctly as it's failing to add leap seconds. No RTC manufacturer bother;because these products are not meant for precise timekeeping, calculations on time etc.Correcting the clock isoffloaded to end-user. And in that context, it all starts to make sense: RTC is a fancy digitalized version of old mechanical clock which needs constant maintenance by the end-user, and the application designer's microcontroller part's only job is to transparently push data through in both directions; expose the RTC registers into some kind of UI, and show the RTC data as is.And sure, if the final application requirement is this, showing incorrect time to user and asking user to micromanage the time, then RTC format choice is excellent because it minimizes data conversions.Now, if you need correct time, or need to do some calculations on time, the RTCs become PITA not only because of their choice of format, but silicon-fixed partial implementation of timekeeping. So it seemed "handy" that you don't need to deal with the complexities of time in software, but then you need to accept the fact that hardware manufacturers have a locked and broken design.Or if you want to do something as simple as adding NTP to your IoT gadget then the weird RTC format is already getting in the way; NTP protocol obviously uses some sort of offset-to-epoch format like any sensible protocol does.So in the end, if you need true timekeeping, then you need to add arecovery layerwhich would know how the RTC actually works and convert into e.g. unix timestamp.The greatest benefit of unix timestamp is that there is existing library code which does required conversionscorrectly. If you need those conversions, they require some flash memory, sure.

author: Nominal Animal
author_rank: Super Contributor
timestamp: November 18, 2024, 12:07:32 pm
content: 64-bit nanoseconds count has a range of just under 585 years.89-bit nanoseconds count has a range of about 1.4 times the current age of the universe.64-bit seconds count has a range of about 42 times the current age of the universe.To record human-supplied timestamps in UTC in ISO8601-like format at second precision, you use 6 bits for seconds, 6 bits for minutes, 5 bits for hours, 5 bits for day of month, 4 bits for month, and the rest for the year; for a total of 26 bits plus year bits. In a 32-bit number, this gives you a range of 64 years, well under a century. A 32-bit seconds count has a range of 136 years and a bit.At nanosecond precision, you'd use 30 bits for the nanosecond part, so you'd have 8 bits for the year part if using a 64-bit record.At microsecond precision, you'd use 20 bits for the nanosecond part, so you'd have 18 bits for the year part if using a 64-bit record.At millisecond precision, you'd use 10 bits for the nanosecond part, so you'd have 28 bits for the year part, having a range of some 268 million years.To convert to/from seconds to TAI, international atomic time –– from which UTC is derived by adding or substracting full leap seconds ––, one only needs to account for leap years where February has 29 days instead of 28. A leap year consists of 31,622,400 seconds instead of 31,536,000. Leap years occur when the full year is divisible by four hundred, or is divisible by four but not one hundred. Using the year change as an epoch makes an iterative conversion easy (trading a bit of execution time for only needing comparisons, additions, and subtractions), but direct conversion between ISO 8601 TAI and seconds-since-epoch requires very annoying modulo operations with large composite numbers. Entire algorithms have been developed for doing this efficiently.Simply put, the ISO 8601 separated-fields format is useful fortimestamps, recording when an event occurred; but calculating the exact interval between two such timestamps requires a quite a few operations. The seconds or fractions of seconds relative to an epoch is excellent for calculatingintervals, but conversion to human-readable ISO 8601 separated-fields format requires quite a few operations. I always pick whichever I use based on this logic.

author: tom66
author_rank: Super Contributor
timestamp: November 18, 2024, 03:22:39 pm
content: Quote from: Siwastaja on November 18, 2024, 08:27:13 amIt certainly is an interesting decision.My best guess is it exists because the almanac data is valid up to a certain timespan, measured in weeks, after the first reception.If you know that >=26 weeks means invalid almanac it might be easier than calculating time delta based on d-m-y.But yeah, other than that, I don't know, because even an 8-bit year field based on, say, 1980 would have made more sense.

author: paulca
author_rank: Super Contributor
timestamp: November 19, 2024, 09:40:03 am
content: Quote from: PlainName on November 17, 2024, 10:54:35 pmWell.... everything comes out of software these days. Those characters are in the letter template in a Java app.QuoteIn most places it is displayed as 6 boxes. DDMMYY.

author: paulca
author_rank: Super Contributor
timestamp: November 19, 2024, 09:56:30 am
content: Quote from: Nominal Animal on November 18, 2024, 12:07:32 pmAn interesting storage format, used in Parquet is INT96. A 96bit INT.However it's basically epoch, but with an origin way back in the BCs. We found that out by inserting a raw INT64 epoch into it by accident and got a date thousands of years ago. I believe this format was deprecated in more recent versions.The issue with origin+delta formats is they can not store "local time". In some business requirements the customer insists on storing things in the "market local time" for example. If we use an epoch or epoch like format, we need a second column to denote the TZ of origin. In many instances the customer did not like this either, so we just used "String" and rendered the date in the format the DB built in date/time manipulation functions would work with easily.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 19, 2024, 12:39:20 pm
content: Quote from: paulca on November 19, 2024, 09:56:30 amThat is the whole point, it's not an issue, it is by design and it is also why they work so well and are popular.You have to offset to local timesomewhereand it is so much easier to do it when parsing/showing the date, because that enables fancy features like users being able to choose their timezone(!!!) without the code becoming a horrible mess of workarounds above workarounds correcting and re-correcting timestamps.Also things like DST Just Work. You keep storing your data like you usually do and the UI then just parses the two different times to same local time, or skips an hour. No need for complexity involved in interpolating missing data or handling duplicate timestamps and whatever crap like that.

author: paulca
author_rank: Super Contributor
timestamp: November 19, 2024, 01:10:12 pm
content: Quote from: Siwastaja on November 19, 2024, 12:39:20 pmIf you are storing a "universal" instant in time, then yes. Usually referred to as a "timestamp".If you are trying to represent a local clock time in a particular location the origin+delta "integer" storage backend cannot store it.The reason is due to the interpretation at query or display time. Both in terms of what the user wants to see and in what the data actually portrays.To use a real world example.A price for a Gold at US market open from an exchange which gives all trade times as "localtime". So, around 9:00am EDT, say.Now when an analyst queries the database (after we extracted, transformed and loaded the data from the feed into it) for that price, they should see 9:00am EST. Even if they (their browser) are in Bejing at the time and the front-end they queried was in Chicago and the Database was in London.When we stored it into the INT96 format as GMT/UTC the front end would morph this into their local time, or the local time on the front-end depending on the interface used. This confuses the hell out of them.When we stored it into the INT96 format as local time.... that made it worse.When we tried to colapse data to the "day" I pointed out that it was impossible with that data because "today" is different depending on where you are and how you are looking at the data.I proposed storing the INT96 as UTC and providing a TZ_OFFSET column. But ... customer was like "WAT?" Honestly though it would make their queries really hard to write.The solution was to insert it into the column as partial ISO datetime string. Then the customer/user used the "to_date( col )" functions to parse them. Apparently performance is just $$$ so nobody cares.

author: RJSV
author_rank: Super Contributor
timestamp: November 20, 2024, 03:55:15 am
content: I'm wondering, if maybe the new forms must not be used for any years '19xx' in cases where people filling in the form put those earlier years in, by mistake. ()So you've got the forms only for year 2000 and later.

author: Analog Kid
author_rank: Super Contributor
timestamp: November 20, 2024, 04:10:35 am
content: Quote from: paulca on November 19, 2024, 09:40:03 amNot on the web sites that ask me for dates: it's almost always 8 boxes, MM DD YYYY.Now, for most people under the age of 90 there's no need for the 4-digit year field: anything greater than the current year (24) can be assumed to be in the 20th century. But that soon won't be true anymore. And if you're a 100-year-old, then there could certainly be confusion over your birthdate. (You mean you're only 3 years old???)

author: TimFox
author_rank: Super Contributor
timestamp: November 20, 2024, 04:18:01 pm
content: That's the logic that lead to the original Y2K issue.

author: Geoff-AU
author_rank: Frequent Contributor
timestamp: November 21, 2024, 02:46:03 am
content: Quote from: paulca on November 15, 2024, 10:52:22 amYes. It sounds like an appropriate, mature and labour-saving decision to avoid people writing a redundant "20" over and over again. When it comes time, the form can be renewed.

author: Analog Kid
author_rank: Super Contributor
timestamp: November 21, 2024, 03:11:34 am
content: Quote from: TimFox on November 20, 2024, 04:18:01 pm

author: TimFox
author_rank: Super Contributor
timestamp: November 21, 2024, 04:22:37 am
content: Tense.

author: Analog Kid
author_rank: Super Contributor
timestamp: November 21, 2024, 05:33:11 am
content: As in present tense? In that case it should be "leads", as you're an American, not a Brit."Led" is the past participle here, not the element Pb.

author: Brumby
author_rank: Unknown
timestamp: November 21, 2024, 07:05:21 am
content: Quote from: wilfred on November 16, 2024, 08:55:13 amI was intimately involved with Y2K for the company that I worked for and part of that was considering various means to achieve confident results in testing. It was interesting to see the different approaches other organisations took. They went from simple variable substitution up to a sandbox installation of a complete mainframe with full production features - and everything in between.The fun and games of whichever mechanism used was heightened by the Australian Prudential Regulation Authority (APRA), a government body who were ever present, assessing financial institutions' efforts providing guidance and reporting on compliance. Fun times.

author: Brumby
author_rank: Unknown
timestamp: November 21, 2024, 07:17:11 am
content: By comparison, in my first full-time job, there was a program run which only used 1 digit of year - the last digit. This wasn't a problem for the purpose of this program as it was used to provide scheduling of a manufacturing facility, taking into consideration parts required, machine capabilities and production constraints. All it needed to know was where it was on a rolling decade. In 1976, 2,3,4,5 were in the past and 7,8,9,0,1 were in the future.That thing was Y2K bullet proof ... back in the 70's!

author: Brumby
author_rank: Unknown
timestamp: November 21, 2024, 07:26:50 am
content: Quote from: TimFox on November 20, 2024, 04:18:01 pm.... and to add a tale about a direct experience of my own ... In 1994, I designed an online application that required date entry - and I set it up with four digit years in the data entry field. It was a pre-built function within the software and running on a DB2 database made it so easy to implement.The reactions I got when presenting this made me think I must have looked like Zaphod Beeblebrox.

author: tom66
author_rank: Super Contributor
timestamp: November 21, 2024, 02:33:02 pm
content: A friend of mine was involved in Y2K bug fixes. One solution was dates over 99 would be encoded with an alpha prefix, so 2009 was encoded as 'A9'. Since the database had space for two characters, but did not store it as an integer, this worked. I presume it would be good until year 2259 (Z9?). He said that if that COBOL code hadn't been axed by then, humanity deserved what it got.

author: TimFox
author_rank: Super Contributor
timestamp: November 21, 2024, 02:52:51 pm
content: Quote from: Analog Kid on November 21, 2024, 05:33:11 am"Led" is thepast tense(not past participle) of the verb "to lead" in that sentence.To be specific, this is the "past simple" tense; the past participle would be used in the "past perfect" tense, as in "that logic had led to Y2K problems", or "present perfect" tense, as in "that logic has led to Y2K problems".

author: Analog Kid
author_rank: Super Contributor
timestamp: November 21, 2024, 08:59:32 pm
content: OK, whatever. But it's surely not the element Pb.

author: timeandfrequency
author_rank: Frequent Contributor
timestamp: November 21, 2024, 09:20:49 pm
content: Quote from: TimFox on November 16, 2024, 09:19:17 pmI can remember having some issues with MS Access databases that had a bug on January 1, 2001.Actually,time storage bugsare not that unfrequent.