Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
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...
Linux at the end of the world (our 2012 predictions)
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