accordionfolder said:First rule of date-time programming, if you're doing it yourself - you're doing it wrong.
You must be a software engineer. Embedded firmware means you're probably doing it yourself, you don't get to import someone else's giant generic implementation that's probably bigger than the storage space you have available...
In reply to Berck :
I've worked plenty with embedded:
1) The first rule still stands as demonstrated by .... everyone through history and Honda right this second (heh). I never said that there are ALWAYS times where you can get around having to write it yourself, but the fact remains that if you wrote it by hand and your job is not Date-time specialist - you've done it wrong. Period. Full stop.
2) Arguably the best time/date library is header only and incredibly compact.
3) TDD is the way to the light - regardless what level you're programming at.
If you think you're doing it right, you've missed an edge case - I can gurantee. Global time is an absolute mess and historical time is even worse.
Pete. (l33t FS) said:DirtyBird222 said:Good thing nearly everyone has these weird devices in our pockets they we take with us everywhere and tell us those things.
And it's a $500 fine and two points on your license if you use it while driving.
It's a $500 fine to check your pocket watch?
In front of the right douchebag cop, yes.
A phone, a Hamburger, or a watch are all items of distraction to the right (wrong) cop
In reply to accordionfolder :
I'm going to bet that the GPS time as it comes off any particular GPS chip is implementation-specific, and it's highly likely that the bug here is an incorrect shift/mask based on the registers that they're reading, and that this is not something they could have simply imported.
In reply to Berck :
Agreed, but I'm not sure how that negates either point 1 or 3? As noted it just reaffirms point 1 ;)
Though, most modern embedded projects I've personally been part of use c, we're not in the 80s anymore.
Sorry, yes. Point (1) is likely correct in this case (maybe they used a library from the GPS chip vendor and that was broken? But probably not.)
My favorite time bug I was personally involved in involved a utility someone wrote (using standard Linux tools!) to convert Microsoft epoch time (1 January 1601) to current time. The values were consistently 4 seconds off from what the implementer believed they should be. Why? Their system was configured to US/Denver time. The Linux tzdata includes all the historical time data. US/Denver time switched from Denver local time in Nov 18, 1883 by implementing 4 negative leap seconds. So, if you naively ask a (correct!) implementation to convert epoch time from before that to local time, you're going to be 4 seconds off. Yeah, it's hard.
Super glad the Y2k issues weren't all hype, they were just Y2k22 which goes along with how the world is right now 
In reply to Paul_VR6 (Forum Supporter) :
I believe the "real" y2k bug is going to be the y2k38 bug - what we're seeing here is just bad data handling based on incorrect spec implementation (by Honda or their chip provider), fortunately not a systemic issue.
Just wait for Y2K38. That one is going to be interesting.
In reply to Berck :
lol, isn't time fun?
In reply to Keith Tanner :
Yeeeep, there are A LOT of 32 bit systems in the wild. I'm going to make sure I'm not working anywhere but for myself when we get there.
Keith Tanner said:Just wait for Y2K38. That one is going to be interesting.
Fortunately, UN*X is an old and disappearing operating system, right?
I'm sure that the Android implementation handles the time bit field rollover because they do expect people to be using current technology in another 16 years, just as the old software engineers thought it was fine to have 68 years worth of time (starting from January 1970). Who'd still be using that software into even the 2000s? Crazy talk.
In reply to Pete. (l33t FS) :
Android is Linux which uses UNIX time epoch like other unices. Early un-updated android phones will probably not display the time correctly in 2038, but they already don't work very well now:) All 64bit Linux kernels and recent 32bit kernels are fine, which covers anything you're likely to be using now, much less in 2038.
And, it's not so much that we use a lot of software from the 70s, but rather that we use the same epoch and store that in a 32-bit number. But I think we have deeper-seated more worrisome infrastructure problems than y2k38.
Pete. (l33t FS) said:Fortunately, UN*X is an old and disappearing operating system, right?
I don't know whether you were being sarcastic or not? Depends on what you mean by "UN*X", but since Linux, Android, MacOS, and iOS are all "UNIX" in their heritage and at least as far as their wall clock implementations, I'd say UNIX is the fastest-proliferating operating system on the planet. Chances are good that everything from your refrigerator to your cloud provider are using a unix-derived operating system that uses the unix epoch.
In reply to Berck :
Yes it is indeed very much sarcasm.
I chuckle when people poke fun and joke that "maybe THIS year is the year of the Linux desktop, really, this time", meanwhile much computing seems to have quietly shifted away from desktops to handheld devices, that almost entirely run Android, and most of the rest are iOS...
Berkeley.
I'm imagining a million little issues like this:
https://www.google.com/amp/s/www.zdnet.com/google-amp/article/microsoft-issues-emergency-fix-for-exchange-2022-date-check-bug/
Individuals phones and desktops don't worry me a bit. Im concerned about the legacy systems that you don't even know exist, the legacy servers sitting there chugging along running a service no one realized was essential. Or any of these infrastructure systems run on hair thin budgets on whatever hardware they have scraped together. Think back to what happened in the heat of COVID when several COBOL services buckled..... I'm an eternal pessimist when it comes to software and I've rarely been proven it's the wrong outlook ;)
I work for a company where today internally it was asked "How do we automatically set the TZ based on GPS location?"
The kept arguing with me about how it was a good idea. I do not think I used strong enough language to get fired, but that might be the only thing that would dissuade them.
In reply to solfly :
Ha!
1. Disconnect the vehicle’s battery Negative (-) terminal first, followed by the Positive (+) terminal at the exact local time of 12:40 AM/PM.
2. With an accurate source of time to compare to, reconnect the Positive (+) terminal followed by the Negative (-) terminal at exactly 1:00 AM/PM.
accordionfolder said:1. Disconnect the vehicle’s battery Negative (-) terminal first, followed by the Positive (+) terminal at the exact local time of 12:40 AM/PM.
2. With an accurate source of time to compare to, reconnect the Positive (+) terminal followed by the Negative (-) terminal at exactly 1:00 AM/PM.
Does "exact local time" mean you have a full 60 seconds, since they don't spec seconds? Or does it have to be down to the second? Or millisecond? But if it rounds, is it using floor() or ceil() or round() ... Whoo, this could get complicated...
Let's face it: If you rely upon the clock in your car to tell you what year it is, you've got bigger issues.
1988RedT2 said:Let's face it: If you rely upon the clock in your car to tell you what year it is, you've got bigger issues.
imagine being in a coma for 20 years, coming out of the hospital and getting in your accord and it tells you it's still 2002!
1988RedT2 said:Let's face it: If you rely upon the clock in your car to tell you what year it is, you've got bigger issues.
That much is annoying, but the time resetting with every key cycle is pretty bad, unless you are more concerned with elapsed time than punctuality.
The clock/calender in the "Information Center" in my 2001 GMC pickup will allow me to set the year to 1997 - several years before the truck was built. Did GM they allow for the possibility I might go back in time at some point?
How thoughtful of them.
You'll need to log in to post.
