Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Charles Lindsey" Newsgroups: comp.os.linux.embedded Subject: Linus time is running out Date: Mon, 24 Nov 2014 16:32:34 GMT Lines: 22 Message-ID: X-Trace: individual.net xKOcbZUHW4EGSnmSeJDjywWv87H7jlATcm9BaKA6bpwCW4a+A= X-Orig-Path: clerew!chl Cancel-Lock: sha1:2eIjjCQO8PY2m5y6kPbGyum7OgE= X-Newsreader: NN version 6.5.2 (NOV) Xref: csiph.com comp.os.linux.embedded:763 As is well known, Linux time (seconds since Jan 1st 1970) will exceed the limits of a 32-bit int early in 2038. What is the official fix to this? AFAICS, 64-bit versions of Linux have already moved to a long int (64 bits), and you might think that 2038 is still far enough away not to start worrying yet. But for sure, embedded systems are being built today that may well still be running when the time comes. Moreover, small embedded systems tend to use the smallest ARM processor that will fill the requirements of the application, which will ususally be a 32-bit architecture. So what can people writing embedded systems today do to ensure that things carry on past the deadline? It will not suffice to redefine time_t, since there are lots of routines in libc that still expect the present definition. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5