Linux at the end of the world (our 2012 predictions) [LWN.net]

Linux at the end of the world (our 2012 predictions)

Posted Jan 4, 2012 12:51 UTC (Wed) by RobSeace (subscriber, #4435)
In reply to: Linux at the end of the world (our 2012 predictions) by leews
Parent article: Linux at the end of the world (our 2012 predictions)

How many of these financial programs really use time_t rather than a custom hand-rolled time/date system of some sort?

Besides, there's already a simple working solution to the 2038 problem: run a 64-bit system, which uses a 64-bit time_t...

to post comments

Linux at the end of the world (our 2012 predictions)

Posted Jan 4, 2012 19:52 UTC (Wed) by eru (subscriber, #2753) [Link] (4 responses)

Besides, there's already a simple working solution to the 2038 problem: run a 64-bit system, which uses a 64-bit time_t...

You will also have to make sure you use a file system that stores time stamps on the disk with better than 32-bit date range! The older ones don't.

Linux at the end of the world (our 2012 predictions)

Posted Jan 4, 2012 20:34 UTC (Wed) by dlang (guest, #313) [Link] (3 responses)

you won't need to worry about that until you need to store a file with a timestamp >2038. (unless you think that financial companies are tracking things by filesystem dates)

in any case, with 30 year mortgages, this is an issue that they would have started to run into in 2008, so I'm pretty confident that it's not really a problem.

The end of the word in 2038

Posted Jan 5, 2012 16:54 UTC (Thu) by eru (subscriber, #2753) [Link] (1 responses)

I wonder if there will be embedded Linux (or BSD) systems running some critical function, which nobody has updated for decades. Or maybe updated to patch something at the application level, but nobody realises the OS contains a time bomb...

OK, now I sound like trying to replay the Y2K scare. But Y2K was a non-event because the patching efforts succeeded on time. This had the side-effect of making the people worrying about it look silly. But would it have got fixed without them? Doomsday scenarios got the attention of bosses, making them allocate resources for fixing.

The end of the word in 2038

Posted Jan 24, 2012 12:10 UTC (Tue) by Jonno (guest, #49613) [Link]

Well, I'm currently working on implementing a new embedded control system, that is intended to be used in production for the next 15-20 years, with each manufactured machine having a projected lifespan of 15-20 years. The software will run on a 32bit ARM CPU using time_t for all time operations.

All the engineers on the project know this will not work out in the long run, but the managers either don't care or don't understand...

Linux at the end of the world (our 2012 predictions)

Posted Jan 9, 2012 16:09 UTC (Mon) by jzbiciak (guest, #5246) [Link]

I personally doubt mortgages are computed with time_t directly, for similar reasons to why there's so much interest in decimal floating point.

Mortgages are generally built around months. It seems to me the three pieces of information you're going to most likely need to compute an amortization schedule are:

Days in the a given month
Days in the a given year
Day number within a given month/year

That gives you enough information to compute interest compounding given partial first/last months (ie. a prorated month at either end to align with a fixed payment schedule), and slightly varying interest month to month to compensate for varying month sizes. And, even then that's not strictly necessary, since I believe you are also allowed to just take the annual rate and divide it by 12 to get a monthly rate. I think I've seen it done both ways.

That sort of math is a P.I.T.A. with time_t. Quick: How do you get from one month to the next with time_t? How do you find days in month? Days in year?

It's slightly better with struct tm, but only slightly. This is where it gets a little more interesting, since you could bounce back and forth between struct tm and time_t. But, that seems unnecessary because I can't see how it'd buy you much. With fairly simple logic, you can figure out days-in-month once you have the correct year without ever touching a time_t.

All that said, it would surprise me at all if the date management was built around these low level UNIX structures. It seems more likely, as others have said, that there's hand-rolled date code floating around in many cases. The rest probably uses date management libraries that also don't use time_t directly.