@revk speaking as someone who spent a lot of time in the Y2K trenches, I guarantee you that in many instances, the "fix" was of the "if it's <50, assume 20xx" variety.
Frankly, if I don't become a millionaire over 2038, I hope to when 2050 explodes 😉
@revk the irony, of course, being that the reasoning used - usually "it's too big a job to fix properly, but this system will be long gone by the time it becomes an issue" is precisely what lead to the problem in the first place.
Those who fail to learn from history, etc., etc., ...
@revk@ahnlak Nice try, but a lot of far-off y2k foreshadowing, and I think even some 2038 foreshadowing, was from things like life assurance policies where things were being arranged based on that thing happening after those problem dates. Just because you're not dead yet doesn't mean it won't affect you when you're dead. Then more stuff cropped up on more conventional products when they're looking at new year's renewals and stuff.
@revk Not just time_t, I've worked on systems which store dates as Unix timestamps in an INT column (which is defined as 32 bits in the SQL standard I think, so you can't change it). Suspect they will all need to be migrated to DATE (which they should be anyway), but that means changing every place they're used in the application...
@pwaring@revk I will be safely retired by 2038 but, as someone who worked on plenty of 2k stuff, I wonder if I'll be able to get some sweet contractor dayrate.
@jens I love that they suggest that this is sort of a good replacement for unix and other formats. Except for this bit (see image). Having to allow for (I assume) leap seconds totally breaks the usefulness of this format for anything other than serious scientific use, and certainly not something anyone wants to code in to a filing system!
@jens worse, assuming this implies TAI drifts to a different date for leap seconds is weird! ISO time format allows for 23:59:60 for this very reason. So the TAI datetime for that example should surely be the same as UTC and only different actually during a leap second. It is amusing that they don’t even mention leap seconds as the explanation. Even so, nobody wants to account for leap seconds unless they have to.
@jens yeh, my issue is converting TAI from a number to a date/time format, as per their example, should surely allow the 23:59:60 insertion in that process and hence end up with a date/time that is the same as UTC (apart from in a leap second). The article seems to imply it does not do that, making the use of a date/time format itself stupid as even the date part cannot be seen to be the correct date at some times. Interesting article though.
There are two problems here as I see it: one is keeping time on a computer, and one is storing time.
The conversion problem occurs when converting from kept time to stored time and vice versa, which is why I brought up text.
There is no such thing as "text", either; it exists in an encoding. And specifying how to keep text (in memory) and how to store it, as well how to convert between the two is just a fundamental task that we have to deal with.
@revk If UTC were to eliminate leap seconds (as is being discussed for 2035, it seems), then TAI and UTC are largely equivalent... we could then just store a UTC timestamp in much the same way.
At that point, the problem shifts to conversion from UTC to e.g. CEST or whatever, which is IMHO weirder. But also fine, as long as it's understood where that boundary lies.
@jens yeh, just surprised at the choice of a date/time format that deliberately ignores that leap seconds happen, ie it moves to next date in the leap second. I understand why the numeric value is what it is and why that makes sense, of course. I just don’t understand the decision of conversion to a “TAI” date/time format like that when 23:59:60 is an option and using that rather than changing date would mean it aligns with UTC format.
@revk my possibly fractious opinion on the embedded front is that absolute time (in the sense that it maps to a date on a particular calendar) should be treated with the same level of cautionary avoidance as long-term storage of personal data. if the device can function without tracking the calendar date, it should avoid doing so wherever possible. time is an obscenely messy problem and not well-suited to simple, near-immutable implementations.
As someone who has worked on this problem for several years, I find it helpful to think of y2038 as two separate issues:
a) on most modern systems that already use a 64-bit time_t, there is an unknown but significant number of unrelated bugs that all run into this, with most of these being easy to fix once identified, and some requiring a painful migration with no backwards compatibility for the users of that particular software.
@revk Nice post, but can we please stop referring to “GMT”. Though it's the legal default time zone in the UK nobody actually uses it any more - apart from a few niche applications everybody uses UTC which can be slightly different.
GMT is not properly defined by modern standards but, being strict, would likely be regarded as an old name for UT1 which can be up to 0.9 seconds different from UTC.
@revk Your comments engine doesn't like me, but I'll note that the sliding window was subject to a patent claim which did nothing to make my life easier. (Not the force of it, but the threat that it would go through, meaning we had to code round the obvious sensible way of doing things.)
Add comment