On 01/20/2014 10:13 AM, Chris Adams wrote: > Once upon a time, Robert Moskowitz <rgm@xxxxxxxxxxxxxxx> said: >> On 01/20/2014 06:47 AM, Frank Murphy wrote: >>> On Mon, 20 Jan 2014 06:45:54 -0800 >>> Robert Moskowitz <rgm@xxxxxxxxxxxxxxx> wrote: >>> >>>>> The day will come when all OS providers, >>>>> will give cutoff for 32bit hardware\code >>>> Well that is a given by 2026.... >>>> >>>> :) >>>> >>>> >>> Amazing what a guess will get ya, >>> jail or laurels. :) >> The death, so to speak, for the 32 bit time field. Yes, it is >> handle rather well now in software in preparation for that day, but >> there is still plenty of bad stuff that will make all the planning >> for y2k look like play stuff. > Oh, was that what was supposed to be? That's not until 2038 (for 32 bit > signed int and epoch = 1970-01-01 00:00:00). > > I really doubt that it will be that big of a deal. Most databases use > actual date fields, not time_t (since time_t already doesn't cover many > interesting dates). Not all OSes use the same epoch either, so this is > mostly a Unix problem, and most current Unix systems already handle a > larger time_t (if somebody is still trying to make SunOS 4 or SCO run in > 2038, time_t will be the least of their problems). > I was burned once by the 32-bit time. It was actually a bug in the Unix standards tests. At the time I was working as a software engineer in the develpment environment group for Digital Unix on the Alpha which was a true 64-bit chip. The problem was that we had to use 32-bit time because the standard mandated it. While 2038 (actually June sometime) is when the 32-bit time integer goes negative, it is very common in financial applications to project 50 or more years into the future. In my case, I had updated the utmp libraries (and utxtmp). When I walked in one day release management was banging on my cube because the standards tests broke and it was in the utmp library, Well, there was nothing wrong with utmp. Thanks to a bit of research and help of a colleage in the standards group we focused on a bug in the standard test where the time went negative. The author of the standard suite agreed and we were able to get a waiver and also a fix to the standards suite. I currently work on software that does financial simulations well into the future, and we have our own time library because some of the products were 32-bit not so long ago. -- Jerry Feldman <gaf@xxxxxxx> Boston Linux and Unix PGP key id:3BC1EB90 PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90
Attachment:
signature.asc
Description: OpenPGP digital signature
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
