2038: only 21 years away

Posted Mar 16, 2017 14:41 UTC (Thu) by gdt (subscriber, #6284)
In reply to: 2038: only 21 years away by marcH
Parent article: 2038: only 21 years away

Has a calendar, scheduling or similar application ever been able to use the system time_t type as its representation for dates? Just as there is a 2038 problem I expect there might also be a 1910 problem. Even at the start of the UNIX epoch in 1970 there would have been birthdates outside the 1910-2038 range. Given that, I suspect that the UNIX system designers had not intended for the system time representation to be suitable for calendaring, scheduling, etc.

(Log in to post comments)

2038: only 21 years away

Posted Mar 16, 2017 18:45 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]

Given that, I suspect that the UNIX system designers had not intended for the system time representation to be suitable for calendaring, scheduling, etc.

That intent doesn't matter. What matters is how the real-world programs people depend on deal with time, and plenty of them have gone ahead and used UNIX system time representation for all kinds of stuff. It's too late to berate programmers for using UNIX system time in domains it wasn't intended for; now we have to deal with the problems doing so has created.

2038: only 21 years away

Posted Mar 17, 2017 23:18 UTC (Fri) by plugwash (subscriber, #29694) [Link]

The minimum date representable by a 32-bit signed time_t is "Fri, 13 Dec 1901 20:45:52".

Most dates people use in everyday life are relatively close to the present day. Few things are scheduled more than a few years in advance.

Birthdates could be a potential issue but even in 1970 most people born in 1901 or earlier would have been retired.

2038: only 21 years away

Posted Mar 17, 2017 23:27 UTC (Fri) by marcH (subscriber, #57642) [Link]

> Most dates people use in everyday life are relatively close to the present day. Few things are scheduled more than a few years in advance.

Software that "mostly works" is indeed plenty good enough to sell and make money. So why would anyone go the extra mile? Any customer who can't tolerate infrequent crashes, security breaches and unsupported corner cases will either need to spend a lot more money or be left high and dry. Sometimes both.

2038: only 21 years away

Posted Mar 18, 2017 13:15 UTC (Sat) by roblucid (guest, #48964) [Link]

The problem is that software that does the right thing, isn't available as soon, costs much more and then has no user base, when compared to software developed with compromises which ships sooner. Release early and often, is similarly a better survival characteristic than over-engineering for the very long term.