Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for June 20, 2013
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Linux at the end of the world (our 2012 predictions)
Posted Jan 4, 2012 3:23 UTC (Wed) by leews (subscriber, #4690)
Many financial programs should be starting to malfunction round about now due to time_t, if not earlier. Remember that mortgages are calculated up to 20 or 30 years, typically 25, and 2038 - 2012 = 26 years!
Oops: your mortgage expires in 1901. <crash>
Happy New Year!
Posted Jan 4, 2012 12:51 UTC (Wed) by RobSeace (subscriber, #4435)
Besides, there's already a simple working solution to the 2038 problem: run a 64-bit system, which uses a 64-bit time_t...
Posted Jan 4, 2012 19:52 UTC (Wed) by eru (subscriber, #2753)
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.
Posted Jan 4, 2012 20:34 UTC (Wed) by dlang (✭ supporter ✭, #313)
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)
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.
Posted Jan 24, 2012 12:10 UTC (Tue) by Jonno (subscriber, #49613)
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...
Posted Jan 9, 2012 16:09 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246)
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:
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds