Computer time itself depends on whether or not you use astronomical time or not (leap seconds and such), but users enter time, and you need to extrapolate what the user wants. That means interpreting and displaying local time. Unix time also sucks for planned events like “every Tuesday at 2” because there’s no stable offset for that (if you assume there is, DST may happen, and it’s Tuesday at 1/3 all of the sudden! Or worse, if it’s Tuesday at 2AM, the event may happen twice on the same day! Or it’ll be skipped!).
Times are already terrible. Timezones are the worst part. Repeated seconds in local time are probably the second worst. Countries switching between sides of the date line are pretty annoying too. 2k38 is going to be hell so I plan on taking a few years off when that comes around.
Our libraries can now deal with time, as long as countries inform the programmers more than a few weeks before skipping the DST switchover this year (this has happened of course). The system is already convoluted enough, though, so let’s just stop messing with it, we can only make it worse.
2038 is only a problem for systems with 32 bit Unix time timekeeping. Right now that’s only a few embedded systems, in fifteen years there will be even fewer
This isn’t even remotely as bad as Y2K where many systems used two digits to store years and rolled over unpredictably when tested. We considered one system in my workplace “good enough” as it rolled over to 100 so the calculations still worked. Others crashed, for example clobbering something in RAM when adding 99 + 1 and storing the results in two bytes
Aren’t the definitions just a client side issue these days? When times are compared it’s unix or unix msec.
Computer time itself depends on whether or not you use astronomical time or not (leap seconds and such), but users enter time, and you need to extrapolate what the user wants. That means interpreting and displaying local time. Unix time also sucks for planned events like “every Tuesday at 2” because there’s no stable offset for that (if you assume there is, DST may happen, and it’s Tuesday at 1/3 all of the sudden! Or worse, if it’s Tuesday at 2AM, the event may happen twice on the same day! Or it’ll be skipped!).
Times are already terrible. Timezones are the worst part. Repeated seconds in local time are probably the second worst. Countries switching between sides of the date line are pretty annoying too. 2k38 is going to be hell so I plan on taking a few years off when that comes around.
Our libraries can now deal with time, as long as countries inform the programmers more than a few weeks before skipping the DST switchover this year (this has happened of course). The system is already convoluted enough, though, so let’s just stop messing with it, we can only make it worse.
2038 is only a problem for systems with 32 bit Unix time timekeeping. Right now that’s only a few embedded systems, in fifteen years there will be even fewer
This isn’t even remotely as bad as Y2K where many systems used two digits to store years and rolled over unpredictably when tested. We considered one system in my workplace “good enough” as it rolled over to 100 so the calculations still worked. Others crashed, for example clobbering something in RAM when adding 99 + 1 and storing the results in two bytes
Not everything can be done client side. Sending notifications or emails: server side. Basically anything that’s automated.