Just in case you missed it. date -d "Fri Feb 13 23:31:30 UTC 2009" +%s It's like a really geeky y2k without the potential cataclysm. :) Steve
On Fri, Feb 13, 2009 at 06:49:49PM -0500, Steve Church wrote:
Just in case you missed it.
date -d "Fri Feb 13 23:31:30 UTC 2009" +%s
It's like a really geeky y2k without the potential cataclysm. :)
Steve
Yes... that is more like the y2k38 problem on 03:14:07 UTC 2038-01-19... ...by then I can only hope I am out of this profession. :) -r
You haven't lived until you've lived through an epoch. On Fri, Feb 13, 2009 at 06:54:54PM -0500, Ravi Pina wrote:
On Fri, Feb 13, 2009 at 06:49:49PM -0500, Steve Church wrote:
Just in case you missed it.
date -d "Fri Feb 13 23:31:30 UTC 2009" +%s
It's like a really geeky y2k without the potential cataclysm. :)
Steve
Yes... that is more like the y2k38 problem on 03:14:07 UTC 2038-01-19...
...by then I can only hope I am out of this profession. :)
-r
--- Wayne Bouchard web@typo.org Network Dude http://www.typo.org/~web/
Once upon a time, Ravi Pina <ravi@cow.org> said:
Yes... that is more like the y2k38 problem on 03:14:07 UTC 2038-01-19...
Oddly enough, the end of the current Unix epoch is a prime. Not only that, it is a Mersenne prime, 2^31 - 1. Even more, it is the largest known Mersenne prime where its Mersenne number (31) is also a Mersenne prime (2^5 - 1). You can always count on numerology. This means something! -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now? On Fri, Feb 13, 2009 at 8:03 PM, Chris Adams <cmadams@hiwaay.net> wrote:
Once upon a time, Ravi Pina <ravi@cow.org> said:
Yes... that is more like the y2k38 problem on 03:14:07 UTC 2038-01-19...
Oddly enough, the end of the current Unix epoch is a prime. Not only that, it is a Mersenne prime, 2^31 - 1. Even more, it is the largest known Mersenne prime where its Mersenne number (31) is also a Mersenne prime (2^5 - 1).
You can always count on numerology. This means something! -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Once upon a time, Nathan Malynn <neito@nerdramblingz.com> said:
Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now?
Unix/POSIX systems use "time_t" to store the base time counter, which is seconds since the epoch (1970-01-01 00:00:00 UTC). Most platforms still use a 32 bit time_t for compatibility. However, it does appear that at some point, 64 bit Linux systems switched to a 64 bit time_t, so I can only assume others are switching as well. Hopefully, the 32 bit systems (at least that have to count seconds) will be mostly gone in another 29 years. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Once upon a time, Nathan Malynn <neito@nerdramblingz.com> said:
Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now?
Unix/POSIX systems use "time_t" to store the base time counter, which is seconds since the epoch (1970-01-01 00:00:00 UTC). Most platforms still use a 32 bit time_t for compatibility.
However, it does appear that at some point, 64 bit Linux systems switched to a 64 bit time_t, so I can only assume others are switching as well. Hopefully, the 32 bit systems (at least that have to count seconds) will be mostly gone in another 29 years.
FreeBSD used a 64-bit time_t for the AMD64 port pretty much right away. On the flip side, it used a 32-bit time_t for the Alpha port. I guess someone predicted "it wouldn't be a problem." Nowhere near as annoying a problem as the variability of the size of size_t. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Once upon a time, Joe Greco <jgreco@ns.sol.net> said:
FreeBSD used a 64-bit time_t for the AMD64 port pretty much right away. On the flip side, it used a 32-bit time_t for the Alpha port. I guess someone predicted "it wouldn't be a problem."
Tru64 on Alpha uses a 32 bit time_t (they have their own time64_t and time64() call), so I expect *BSD and Linux on Alpha stayed with 32 bit time_t for compatibility (Linux at least could run many Tru64 binaries). -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Fri, 13 Feb 2009 21:08:12 -0600 Chris Adams <cmadams@hiwaay.net> wrote:
Once upon a time, Joe Greco <jgreco@ns.sol.net> said:
FreeBSD used a 64-bit time_t for the AMD64 port pretty much right away. On the flip side, it used a 32-bit time_t for the Alpha port. I guess someone predicted "it wouldn't be a problem."
Tru64 on Alpha uses a 32 bit time_t (they have their own time64_t and time64() call), so I expect *BSD and Linux on Alpha stayed with 32 bit time_t for compatibility (Linux at least could run many Tru64 binaries).
NetBSD has just converted its -current branch to 64-bit time_t; I'm pretty sure that that includes the Alpha port. --Steve Bellovin, http://www.cs.columbia.edu/~smb
On Fri, Feb 13, 2009 at 6:06 PM, Nathan Malynn <neito@nerdramblingz.com> wrote:
Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now?
Exactly! What are we going to do when we're at the end of the 2^64 epoch?? (after the sun burns out and.. oh wait) -- Eric http://nixwizard.net
In message <ef3daad70902131706x2277ac5fp5cc243ffff354998@mail.gmail.com>, Nathan Malynn writes:
Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now?
No. Even if they were you have 32 bit timestamps in lots of things that have to be handled even if time/time64 returns a 64 bit timestamp.
On Fri, Feb 13, 2009 at 8:03 PM, Chris Adams <cmadams@hiwaay.net> wrote:
Once upon a time, Ravi Pina <ravi@cow.org> said:
Yes... that is more like the y2k38 problem on 03:14:07 UTC 2038-01-19...
Oddly enough, the end of the current Unix epoch is a prime. Not only that, it is a Mersenne prime, 2^31 - 1. Even more, it is the largest known Mersenne prime where its Mersenne number (31) is also a Mersenne prime (2^5 - 1).
You can always count on numerology. This means something! -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
* Mark Andrews:
In message <ef3daad70902131706x2277ac5fp5cc243ffff354998@mail.gmail.com>, Nathan Malynn writes:
Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now?
No. Even if they were you have 32 bit timestamps in lots of things that have to be handled even if time/time64 returns a 64 bit timestamp.
Those values can often be interpreted as unsigned, so we get another 68 years. By then, hopefully, the required protocol updates can be fully automated.
What about embedded systems (I'm thinking PCS, SCADA, ICS, etc.) that run a micro version of *nix? Wonder how many of them will still be warm but confused in January of 2038? Marc -----Original Message----- From: Florian Weimer [mailto:fw@deneb.enyo.de] Sent: Saturday, February 14, 2009 8:01 AM To: Mark Andrews Cc: NANOG list Subject: Re: Happy 1234567890 everyone! * Mark Andrews:
In message <ef3daad70902131706x2277ac5fp5cc243ffff354998@mail.gmail.com>, Nathan Malynn writes:
Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now?
No. Even if they were you have 32 bit timestamps in lots of things that have to be handled even if time/time64 returns a 64 bit timestamp.
Those values can often be interpreted as unsigned, so we get another 68 years. By then, hopefully, the required protocol updates can be fully automated.
participants (11)
-
Chris Adams -
Eric Gearhart -
Florian Weimer -
Joe Greco -
Mark Andrews -
Nathan Malynn -
Ravi Pina -
Sachs, Marcus Hans (Marc) -
Steve Church -
Steven M. Bellovin -
Wayne E. Bouchard