Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Unix Technology

Raise a Glass — Time(2) Turns 40 Tonight 114

ddt writes "Raise your glasses of champagne in a toast at midnight. The time(2) system call turns 40 tonight, and is now officially 'over the hill.' It's been dutifully keeping track of time for clueful operating systems since January 1, 1970." And speaking of time, if you don't have a *nix system handy, or just want a second opinion, an anonymous reader points out this handy way to check just how far it is after local midnight in Unix time. Updated 10:03 GMT by timothy: The Unix-time-in-a-browser link has been replaced by a Rick Astley video; you have been warned.
This discussion has been archived. No new comments can be posted.

Raise a Glass — Time(2) Turns 40 Tonight

Comments Filter:
  • Give it 28 years (Score:5, Insightful)

    by betterunixthanunix ( 980855 ) on Thursday December 31, 2009 @11:49PM (#30612216)
    When time(2) turns 68, that will be newsworthy.
    • Re: (Score:2, Interesting)

      by yuhong ( 1378501 )
      Especially when the 32-bit time_t overflows. The good news is that most 64-bit OSes already uses a 64-bit time_t, but there still is the issue of truncation to 32-bit.
      • Re: (Score:3, Interesting)

        Especially when the 32-bit time_t overflows. The good news is that most 64-bit OSes already uses a 64-bit time_t, but there still is the issue of truncation to 32-bit.

        Shouldn't the 32 bit time_t expire in 2106 [wolframalpha.com]?

        • Re: (Score:2, Informative)

          by Anonymous Coward
          time_t is signed.
        • Re: (Score:3, Interesting)

          by Abcd1234 ( 188840 )

          'fraid not. The 32-bit time_t is signed (I'm assuming so you can expression times less than the epoch, but that's just a guess). As such, it actually overflows in 2038 [wolframalpha.com].

          • Re:Give it 28 years (Score:4, Informative)

            by wizardforce ( 1005805 ) on Friday January 01, 2010 @05:01AM (#30612984) Journal

            The 32-bit time_t is signed (I'm assuming so you can expression times less than the epoch, but that's just a guess)

            Indeed.
            Some binary blobs do require the use of a signed integer for calculating differences in time which is much of the apparent hesitancy to convert to a 32 bit unsigned integer time system. More here. [wikipedia.org]

        • Apparently, at least some implementations define time_t as a signed integer. [wolframalpha.com]

        • Re:Give it 28 years (Score:5, Informative)

          by mysidia ( 191772 ) on Friday January 01, 2010 @03:05AM (#30612816)

          Nope, the maximum value for 32-bit time_t is 2147483647. Increment that by 1, and the time_t value becomes -2147483648.

          Although time_t is a 32-bit value, the 1st bit is the sign bit.

          Jan 18 21:14:07, 2038

          For 64-bit time_t it should be 9223372036854775807. But I don't believe the standard time functions can handle this value...

          While it may be a perfectly valid 64-bit time_t value, if gmtime/localtime/strftime/ctime don't work with the maximum value, it's not a usable value, really

          • Re: (Score:1, Informative)

            by Anonymous Coward

            Although time_t is a 32-bit value, the 1st bit is the sign bit.

            The 1st bit is not a sign bit! Signed integer coding uses two's complement arithmetic [wikipedia.org].

            • by mysidia ( 191772 )

              It doesn't matter that 2's complement is the encoding format used to represent a negative number on certain architectures, or if sign magnitude encoding is used, the MSB is still called a sign bit, if a "1" in that position indicates negative numbers regardless of the encoding format represented by the other bits.

        • by jonadab ( 583620 )
          One would think so, but unfortunately someone decided it would be a good idea to use a signed value for time, presumably in case you need to have system times prior to 1970 (even though, in practice, you can't actually do that).

          So when people say "32-bit time_t", what they actually mean is "the effectively 31-bit time_t that is used on most 32-bit systems". Hence, 2038.
      • by tlhIngan ( 30335 )

        Especially when the 32-bit time_t overflows. The good news is that most 64-bit OSes already uses a 64-bit time_t, but there still is the issue of truncation to 32-bit.

        I believe modern 32-bit OSes also have a 64-bit time_t. Especially glibc based ones.

        64-bit integers isn't the exclusive realm of 64-bit OSes. It's just 32-bit processors are less efficient when calculating with 64-bit integers (takes multiple instructions). But most modern compilers for 32-bit processors understand 64-bit types natively, inclu

    • It's depressing, I'm 40 since August 2009, which makes me older than time(2).
  • First Post! (Score:5, Informative)

    by therufus ( 677843 ) on Thursday December 31, 2009 @11:49PM (#30612220)

    There is a rickroll in article. Beware to click!

  • It's not April 1 yet (Score:3, Informative)

    by SpazmodeusG ( 1334705 ) on Thursday December 31, 2009 @11:50PM (#30612222)
    That second link is a Rick Roll.
    Did you even check it?
  • Unix epoch? (Score:3, Interesting)

    by arnoldo.j.nunez ( 1300907 ) on Thursday December 31, 2009 @11:50PM (#30612224)
    Why was the epoch chosen to be 00:00:00 UTC on 1 January 1970?
    Why didn't we restart it at 2000 amidst the Y2K mess?
    • Re:Unix epoch? (Score:5, Interesting)

      by MichaelSmith ( 789609 ) on Thursday December 31, 2009 @11:57PM (#30612256) Homepage Journal

      Putting it in 1970 is a pain. VMS at least put their zero date in 1858, where it is less likely to conflict with real dates. If course, VMS had 64 put support from the word go. Rebasing time_t would have created a horrible mess. Better to start again with a proper date type.

      • Why is putting it in 1970 a pain? Because time_t is signed, that gives us the range of 1901 December 13 20:45:52 UTC to 2038 January 19 03:14:07 UTC.

        That's 136 or so years from a 32-bit value.

        • Because time_t is signed, that gives us the range of 1901 December 13 20:45:52 UTC to 2038 January 19 03:14:07 UTC.

          Damn - if only those 6th Century monks had thought of that we wouldn't now be arguing over whether today is the start of a new decade!

        • Isn't the sign bit only used to indicate error? ((time_t)-1) isn't a valid time but perhaps some other negative values are.
          • by schon ( 31600 )

            Isn't the sign bit only used to indicate error? ((time_t)-1) isn't a valid time but perhaps some other negative values are.

            Sorry, what are you talking about?

            $ echo -1 |awk '{print strftime("%c",$1,0)}'
            Wed 31 Dec 1969 04:59:59 PM MST

            $ echo -1 |awk '{print strftime("%c",$1,1)}'
            Wed 31 Dec 1969 11:59:59 PM GMT

            $ echo -1 |awk '{print strftime("%s",$1,0)}'
            -1

            Seems to work fine for me.

    • by schon ( 31600 ) on Thursday December 31, 2009 @11:59PM (#30612270)

      Why didn't we restart it at 2000 amidst the Y2K mess?

      You have a promising career in middle management ahead of you!

      • Re: (Score:2, Insightful)

        by troll8901 ( 1397145 ) *

        No, no, middle management does all the work. Such a decision is usually done by top management.

    • Re: (Score:1, Informative)

      by Anonymous Coward
      because unix was invented in 1970?
    • Why was the epoch chosen to be 00:00:00 UTC on 1 January 1970?

      I know the epoch was changed around a bit because early versions of the unix time system functioned at rates greater then 1hz, and hence would run out of room in the 32bit space really really fast. I'm not sure why that particular date was the one they settled on, hopefully someone else can fill in.

      Why didn't we restart it at 2000 amidst the Y2K mess?

      I'm not 100% on this, but I believe the Y2K mess didn't effect Unix-y systems at all. The way Unix time works, if you're not familiar, is that it just counts the seconds after the epoch. Whether the year is re

      • I'm not 100% on this, but I believe the Y2K mess didn't effect Unix-y systems at all. The way Unix time works, if you're not familiar, is that it just counts the seconds after the epoch. Whether the year is represented as two of four digits doesn't matter, and doesn't cause problems.

        Yes, assuming well-behaved programs. But it is a fact that Y2K doesn't affect this particular interface at all.

      • > I'm not 100% on this, but I believe the Y2K mess didn't effect Unix-y systems at all. The way Unix time works,
        > if you're not familiar, is that it just counts the seconds after the epoch. Whether the year is represented as two
        > of four digits doesn't matter, and doesn't cause problems.

        Remember all of the Perl-based CGI wishing you a Happy New Year on January 1, 19100? I have old books in a box somewhere from *1997* with sample code telling users to print "19" then append the year value. It affect

  • by nurhussein ( 864532 ) on Thursday December 31, 2009 @11:51PM (#30612230) Homepage
    Rickrolling is so 2009.
  • I turn 45 this year you insensitive clod! Passing the top of the hill just means I am gaining momentum for the next climb, anyway.

    BTW why does the summary point to a page which returns
      (54) Connection reset by peer
      Maybe the server is over the hill.

    • Passing the top of the hill just means I am gaining momentum for the next climb, anyway.

      I don't know what special relationship with mortality you have, Sisyphus, but when most of us crest the hill, it's a smooth coast to the bottom.

      • Passing the top of the hill just means I am gaining momentum for the next climb, anyway.

        I don't know what special relationship with mortality you have

        I am a hacker. Many things are possible.

      • Just because the overall trend is downhill, doesn't mean there aren't a few peaks and valleys on the trip graveward side of middle age.
    • Re:Over the hill? (Score:5, Interesting)

      by multi io ( 640409 ) <olaf.klischat@googlemail.com> on Friday January 01, 2010 @01:38AM (#30612558)
      Decimal jubilees are meaningless. time(2) has passed the top of the hill almost six years ago!

      $ TZ=GMT ruby -e '((0..29).map{|bit| 1<<bit} + (0..30).to_a.reverse.map{|bit| (1<<31) - (1<<bit)}).each{|t| puts "%031b %s" % [t, Time.at(t)]}'
      0000000000000000000000000000001 Thu Jan 01 00:00:01 +0000 1970
      0000000000000000000000000000010 Thu Jan 01 00:00:02 +0000 1970
      0000000000000000000000000000100 Thu Jan 01 00:00:04 +0000 1970
      0000000000000000000000000001000 Thu Jan 01 00:00:08 +0000 1970
      0000000000000000000000000010000 Thu Jan 01 00:00:16 +0000 1970
      0000000000000000000000000100000 Thu Jan 01 00:00:32 +0000 1970
      0000000000000000000000001000000 Thu Jan 01 00:01:04 +0000 1970
      0000000000000000000000010000000 Thu Jan 01 00:02:08 +0000 1970
      0000000000000000000000100000000 Thu Jan 01 00:04:16 +0000 1970
      0000000000000000000001000000000 Thu Jan 01 00:08:32 +0000 1970
      0000000000000000000010000000000 Thu Jan 01 00:17:04 +0000 1970
      0000000000000000000100000000000 Thu Jan 01 00:34:08 +0000 1970
      0000000000000000001000000000000 Thu Jan 01 01:08:16 +0000 1970
      0000000000000000010000000000000 Thu Jan 01 02:16:32 +0000 1970
      0000000000000000100000000000000 Thu Jan 01 04:33:04 +0000 1970
      0000000000000001000000000000000 Thu Jan 01 09:06:08 +0000 1970
      0000000000000010000000000000000 Thu Jan 01 18:12:16 +0000 1970
      0000000000000100000000000000000 Fri Jan 02 12:24:32 +0000 1970
      0000000000001000000000000000000 Sun Jan 04 00:49:04 +0000 1970
      0000000000010000000000000000000 Wed Jan 07 01:38:08 +0000 1970
      0000000000100000000000000000000 Tue Jan 13 03:16:16 +0000 1970
      0000000001000000000000000000000 Sun Jan 25 06:32:32 +0000 1970
      0000000010000000000000000000000 Wed Feb 18 13:05:04 +0000 1970
      0000000100000000000000000000000 Wed Apr 08 02:10:08 +0000 1970
      0000001000000000000000000000000 Tue Jul 14 04:20:16 +0000 1970
      0000010000000000000000000000000 Sun Jan 24 08:40:32 +0000 1971
      0000100000000000000000000000000 Wed Feb 16 17:21:04 +0000 1972
      0001000000000000000000000000000 Wed Apr 03 10:42:08 +0000 1974
      0010000000000000000000000000000 Tue Jul 04 21:24:16 +0000 1978
      0100000000000000000000000000000 Mon Jan 05 18:48:32 +0000 1987
      1000000000000000000000000000000 Sat Jan 10 13:37:04 +0000 2004
      1100000000000000000000000000000 Thu Jan 14 08:25:36 +0000 2021
      1110000000000000000000000000000 Wed Jul 18 05:49:52 +0000 2029
      1111000000000000000000000000000 Tue Oct 18 16:32:00 +0000 2033
      1111100000000000000000000000000 Tue Dec 04 09:53:04 +0000 2035
      1111110000000000000000000000000 Fri Dec 26 18:33:36 +0000 2036
      1111111000000000000000000000000 Wed Jul 08 22:53:52 +0000 2037
      1111111100000000000000000000000 Wed Oct 14 01:04:00 +0000 2037
      1111111110000000000000000000000 Tue Dec 01 14:09:04 +0000 2037
      1111111111000000000000000000000 Fri Dec 25 20:41:36 +0000 2037
      1111111111100000000000000000000 Wed Jan 06 23:57:52 +0000 2038
      1111111111110000000000000000000 Wed Jan 13 01:36:00 +0000 2038
      1111111111111000000000000000000 Sat Jan 16 02:25:04 +0000 2038
      1111111111111100000000000000000 Sun Jan 17 14:49:36 +0000 2038
      1111111111111110000000000000000 Mon Jan 18 09:01:52 +0000 2038
      1111111111111111000000000000000 Mon Jan 18 18:08:00 +0000 2038
      1111111111111111100000000000000 Mon Jan 18 22:41:04 +0000 2038
      1111111111111111110000000000000 Tue Jan 19 00:57:36 +0000 2038
      1111111111111111111000000000000 Tue Jan 19 02:05:52 +0000 2038
      1111111111111111111100000000000 Tue Jan 19 02:40:00 +0000 2038
      1111111111111111111110000000000 Tue Jan 19 02:57:04 +0000 2038
      1111111111111111111111000000000 Tue Jan 19 03:05:36 +0000 2038
      1111111111111111111111100000000 Tue Jan 19 03:09:52 +0000 2038
      1111111111111111111111110000000 Tue Jan 19 03:12:00 +0000 2038
      1111111111111111111111111000000 Tue Jan 19 03:13:04 +0000 2038
      1111111111111111111111111100000 Tue Jan 19 03:13:36 +0000 2038
      1111111111111111111111111110000 Tue Jan 19 03:13:52 +0000 2038
      1111111111111111111111111111000 Tue Jan 19 03:14:0

      • Re: (Score:3, Informative)

        by wagnerrp ( 1305589 )
        Anyone else notice the top of the hill is 1337?
      • Cool. But would someone please translate this obfuscated Ruby into some readable Perl?

        • by selven ( 1556643 )
          Here's some readable python:

          import time
          for i in range(0,31):
              print "0"*(30-i) + "1" + "0"*i + " " + time.strftime("%a %b %d %H:%M:%S +0000 %Y",time.gmtime(2**i))
          for i in reversed(range(0,31)):
              print "1"*(31-i) + "0"*i + " " + time.strftime("%a %b %d %H:%M:%S +0000 %Y",time.gmtime(2**31 - 2**i))
          print "$"
          • by rduke15 ( 721841 )

            Indeed, that was much more readable. And helped writing this Perl version, despite the Python trap (for a Python-illiterate) of "range(0,31)" apparently meaning "from 0 to 30":

            for (0..30) {
            print "0"x(30-$_), 1, "0"x$_, " ", scalar gmtime(2**$_), "\n";
            }
            for (reverse 0..29) {
            print "1"x(31-$_), "0"x$_, " ", scalar gmtime(2**31 - 2**$_), "\n";
            }

            Now, maybe someone can condense it into a smarter one-liner, with some clever use of printf and/or pack/unpack.

            • by selven ( 1556643 )
              Ok, here's the evil one liner in python.

              import time
              for i in range(0,61): print str((i>30)*1) * abs(i-30) + "1" + "0" * (30 - abs(i-30)) + " " + time.strftime("%a %b %d %H:%M:%S +0000 %Y",time.gmtime((2**(30 - abs(i-30))) * ((i <= 30) * 2 - 1) + 2 ** 31 * (i > 30)))
            • by rduke15 ( 721841 )

              And here is the one-liner Perl version, using printf's %b:

              $ perl -e 'for (0..30) {printf "%031b %s\n", 2**$_, scalar gmtime(2**$_)} for (reverse 0..29) {printf "%031b %s\n", 2**31-2**$_, scalar gmtime(2**31-2**$_)}'

  • Windows (Score:2, Funny)

    by Tablizer ( 95088 )

    The Windows clock starts the second Gates stiffed IBM out of the DOS market.

  • by HockeyPuck ( 141947 ) on Friday January 01, 2010 @12:06AM (#30612292)

    The Unix time(2) system call is "over the hill" at 40 years old today. The time(2) system call has dutifully told us how many seconds have passed since January 1, 1970. I use the day as my "birthday" on public websites in tribute. Please raise a glass of champagne tonight with me in celebration!

    Why is there a link in the summary to some guy's blog which says exactly what I've pasted above? I mean really, just put the information in the summary without the link....

    • Re: (Score:3, Insightful)

      by PopeRatzo ( 965947 ) *

      More important, why is the guy with the blog still wearing a face mullet, in 2010?

      And have you ever met an "independent game producer" with such a neatly trimmed beard?

    • I use the day as my "birthday" on public websites in tribute.

      Wow. He is hardcore!

  • ... just see this as the 40th anniversary of the Unix Epoch [wikipedia.org].
  • by Telecommando ( 513768 ) on Friday January 01, 2010 @12:24AM (#30612358)

    My clock says today is Setting Orange, Day 73 of the Aftermath in the Year of Our Lady of Discord 3175.

  • This isn't really a valid birthday unless time() was actually compiled and run for the first time immediately after midnight on January 1, 1970. I mean, c'mon, are we supposed to also be celebrating the 190th birthday of perl's localtime()?

    • ... er, make that 110th - sorry about that. Darn Slashdot and its lack of an edit function...

    • by PopeRatzo ( 965947 ) * on Friday January 01, 2010 @12:59AM (#30612452) Journal

      I mean, c'mon, are we supposed to also be celebrating the 190th birthday of perl's localtime()?

      I don't know about you, but I'm ready to drink to that.

      My wife and I opened a bottle of champagne a few hours ago, and she's fallen asleep after two glasses, the lightweight. I had a double espresso with my pecan pie and now I'm ready to friggin' rawk!

      After I submit this, I'm gonna go show some Borderlands weaklings who's boss. Either that or finish the champagne and go watch the fireworks from my rooftop, naked. It's -2 degrees F outside though, so maybe I ought to pull out the thermal merkin first. I mean, subzero temperatures, nudity and high blood-alcohol level - what could possibly go wrong?

      • I mean, c'mon, are we supposed to also be celebrating the 190th birthday of perl's localtime()?

        go watch the fireworks from my rooftop, naked.

        I had similar plans but then our 38 degree C [wolframalpha.com] day turned into really serious thunder and lightening so I decided to give the naked roof standing a miss. The roof is steel and quite well grounded.

        • Yeah, the fireworks will be all washed out from the lightening anyway. Was the lightening caused by lightning, perhaps? Meteors? Or was it just fog and ordinary street-lams?

  • by Anonymous Coward on Friday January 01, 2010 @12:35AM (#30612390)

    Just for showing the epoch time?

    • Re: (Score:1, Funny)

      by Anonymous Coward

      It makes sense when the time hits midnight.

  • This is not true (Score:5, Informative)

    by ucblockhead ( 63650 ) on Friday January 01, 2010 @12:41AM (#30612396) Homepage Journal

    Epoch starts at January 1st, 1970, but the system call itself was not around in 1970 [wikipedia.org].

  • Am I the only one? (Score:3, Insightful)

    by BlueBoxSW.com ( 745855 ) on Friday January 01, 2010 @01:33AM (#30612540) Homepage

    Who is almost exactly as old as *nix time?

  • Apparently Slashdot's version of time_t had a year 2010 problem!

    Happy new year anyway!

  • by Anonymous Coward

    On a *nix system, type "date +%s" to see the number of seconds since the Unix epoch started.

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...