Re: [gentoo-user] Re: Don't miss the 1 500 000 000 Unix second!
Grant Edwards wrote: > Well, the return type for time() changed from "int" (or was it long?) > to "time_t" many years back. That said, the actual underlying > representation has never changed on 32-bit Linux systems. Posix > requires it to be signed, and on 32-bit Linux systems, it's still > going to overflow in 2038 -- same as it ever was. time() did always return a long, in special since it counts only in seconds. Unfortunately Tru64 from DEC changed that to an int and Linux copied the bug. FreeBSD was going to make the same mistake, but I warned them and they delayed their 64bit kernel until they had tested everything well enough. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [gentoo-user] Re: Don't miss the 1 500 000 000 Unix second!
On Sat, Jul 15, 2017 at 02:23:44PM +, Grant Edwards wrote > It's not just the kernel. If you want to avoid the 32-bit time > problem, then you need to re-install all of the user-space librairies > and binary exectuables that use the time() libc function. I believe that postgresql 32-bit is different internally from 64-bit. You have to do a dump+restore or some other form of data copy or synch. You cannot take the 32-bit data tables and run under 64-bit postgresql (or visa versa). -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Re: Don't miss the 1 500 000 000 Unix second!
On Sat, Jul 15, 2017 at 2:08 AM, Matthias Hanft wrote: > Grant Edwards wrote: >> >> Well, the return type for time() changed from "int" (or was it long?) >> to "time_t" many years back. That said, the actual underlying >> representation has never changed on 32-bit Linux systems. Posix >> requires it to be signed, and on 32-bit Linux systems, it's still >> going to overflow in 2038 -- same as it ever was. > > This is correct: > > mh@n ~ $ date -u -d @2147483647 > Tue Jan 19 03:14:07 UTC 2038 > mh@n ~ $ date -u -d @2147483648 > date: invalid date '@2147483648' > > Will there be any fix until then, or will I have > to reinstall all my 32bit Gentoo systems with 64bit kernels? ball mode> > The Y2K fixes for systems which could not have old data modified simply treat the imprecise/truncated date field as happening before the event that necessitated the fix. You don't have to change any of your files, and updating the programs can happen in place.
Re: [gentoo-user] Re: Don't miss the 1 500 000 000 Unix second!
Grant Edwards wrote: > > Well, the return type for time() changed from "int" (or was it long?) > to "time_t" many years back. That said, the actual underlying > representation has never changed on 32-bit Linux systems. Posix > requires it to be signed, and on 32-bit Linux systems, it's still > going to overflow in 2038 -- same as it ever was. This is correct: mh@n ~ $ date -u -d @2147483647 Tue Jan 19 03:14:07 UTC 2038 mh@n ~ $ date -u -d @2147483648 date: invalid date '@2147483648' Will there be any fix until then, or will I have to reinstall all my 32bit Gentoo systems with 64bit kernels? Is there actually a "how-to" to replace a 32-bit-Gentoo by a 64-bit- Gentoo? Do I have to format the harddisk (and rebuild everything from scratch), oder can I just keep all the (postfix, apache...) configuration in /etc, all my personal stuff in /usr/local and all the data in /var and just install a 64-bit kernel in /boot? (Of course, with all its dependencies like kernel modules and "system-near" binaries and all that.) -Matt
Re: [gentoo-user] Re: Don't miss the 1 500 000 000 Unix second!
On 2017-07-14 08:15, Andrew Tselischev wrote: > On Fri, Jul 14, 2017 at 08:42:01PM +0700, Vadim A. Misbakh-Soloviov wrote: > >> when time_t reaches 2 billion. > > > > He meant 2k38 problem, when time_t will overflow int32 :) > > I would bet that somewhere there is a quick-job shell script that parses > unix timestamps with regular expressions and assumes they start with a 1. :D > Why do I feel that we've already gone through at least one upgrade of "Unix Time" already. I'm not sure if it was something like going from int16 to int32, or more that it went from signed int32 to unsigned int32. Jigme Datse Yli-Rasku -- Jigme Datse Yli-Rasku jigme.da...@datsemultimedia.com (Preferred address for new messages) Jigme Datse Yli-Rasku PO Box 270 Rossland, BC V0G 1Y0 Canada ... ... This message should be electronically signed, and if the sender ... ... has your public key, may also be encrypted. ... ... If you have any questions about this, please email, or call. ... ...
Re: [gentoo-user] Re: Don't miss the 1 500 000 000 Unix second!
On Fri, Jul 14, 2017 at 08:42:01PM +0700, Vadim A. Misbakh-Soloviov wrote: > > when time_t reaches 2 billion. > > He meant 2k38 problem, when time_t will overflow int32 :) I would bet that somewhere there is a quick-job shell script that parses unix timestamps with regular expressions and assumes they start with a 1. :D
Re: [gentoo-user] Re: Don't miss the 1 500 000 000 Unix second!
> when time_t reaches 2 billion. He meant 2k38 problem, when time_t will overflow int32 :) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Don't miss the 1 500 000 000 Unix second!
Matthias Hanft wrote: > Neil Bothwick wrote: > > > > That's a relief, I though we were in for another Y2K-like apocalypse. > > As far as I know, next apocalypse is scheduled for January 19th, 2038, > 03:14:08 UTC, isn't it? > > At that time, I'll be 73 years old, and I hope I'm not gonna be sysadmin > any more... :-) The next apocalypse is: 2033 May 18 03:33:20 GMT when time_t reaches 2 billion. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [gentoo-user] Re: Don't miss the 1 500 000 000 Unix second!
Neil Bothwick wrote: > > That's a relief, I though we were in for another Y2K-like apocalypse. As far as I know, next apocalypse is scheduled for January 19th, 2038, 03:14:08 UTC, isn't it? At that time, I'll be 73 years old, and I hope I'm not gonna be sysadmin any more... :-) -Matt
Re: [gentoo-user] Re: Don't miss the 1 500 000 000 Unix second!
On Fri, 14 Jul 2017 05:00:38 +0200, wabe wrote: > > What a big coincidence. I read this threat about half a minute > > before > > Sorry. Of course I meant "thread" and not "threat". ;-) That's a relief, I though we were in for another Y2K-like apocalypse. -- Neil Bothwick If at first you don't succeed, redefine success. pgpYZIVORblzL.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Don't miss the 1 500 000 000 Unix second!
wabe wrote: > Nikos Chantziaras wrote: > > > On 13/07/17 21:15, Kent Fredric wrote: > > > On Thu, 13 Jul 2017 16:01:42 +0300 > > > Andrew Savchenko wrote: > > > >> I'd like to remind you that > > >>$ date -d @15 > > >> is drawing close! > > >> > > >> Don't miss the moment :) > > > > watch -n 1 'echo $(( 15 - $( date +"%s") ))' > > > > Enjoy. > > > > watch -n 1 'date -d@$((15 - $(date +"%s"))) -u +%H:%M:%S' > > > > Enjoy even more :-) > > > > What a big coincidence. I read this threat about half a minute before Sorry. Of course I meant "thread" and not "threat". ;-) -- Regards wabe
Re: [gentoo-user] Re: Don't miss the 1 500 000 000 Unix second!
Nikos Chantziaras wrote: > On 13/07/17 21:15, Kent Fredric wrote: > > On Thu, 13 Jul 2017 16:01:42 +0300 > > Andrew Savchenko wrote: > > >> I'd like to remind you that > >>$ date -d @15 > >> is drawing close! > >> > >> Don't miss the moment :) > > > watch -n 1 'echo $(( 15 - $( date +"%s") ))' > > > Enjoy. > > watch -n 1 'date -d@$((15 - $(date +"%s"))) -u +%H:%M:%S' > > Enjoy even more :-) > What a big coincidence. I read this threat about half a minute before 03:40 UTC and quickly entered the command you posted into a terminal window, only 6 seconds before the "magic moment" occurs. :-) -- Regards wabe
