Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Unix Operating Systems Software

The Quickly Descending Unix Timestamp 272

Teach writes: "If my calculations are correct, on Thursday, April 19, 2001, at 04:25:21 UTC (00:25:21 EDT and late Wednesday at 21:25:21 PDT), the UNIX clock will read 987654321, which is pretty cool. This will be the first of two such "significant" events in 2001, the second being 01:46:39 UTC on 2001-09-09, when the clock will read 999999999 (and then of course "roll over" to 1000000000 one second later). Use the Time Zone Converter to help you figure out when this will occur in your area, or read up on other critical dates (such as when the 32-bit signed UNIX clock overflows in 2038)."
This discussion has been archived. No new comments can be posted.

The Quickly Descending Unix Timestamp

Comments Filter:
  • by Speare ( 84249 ) on Wednesday April 18, 2001 @10:10AM (#281557) Homepage Journal

    Not many programs are gonna care how many digits are in a timestamp, but I bet some do try to format stuff assuming a less-than-one-billion-seconds-since-epoch time.

    Review your code?

  • I hate to crapflood and troll, but this has to be the dumbest article on /.
    How are we supposed to discuss this?
    Its like when the "annoying" guy comes into your cube and says some dumb fact, like "hey, the timestamp will be 987654321 soon!", and you try to ignore him so he'll go away...
  • I thought the Mayans predicted the world would end in 2021.. But if I'm still alive in 2038, I think I'll be more concerned about my next change of Depend Undergarments than what my Unix clock is doing...
  • If this doesn't matter, I don't know what does! I wish I was old enough to have experienced 12:34 on 6th May 1978 (5/6/78) (or 5th June 1978, for those who do it DD/MM/YY).
    Pointlessly,
    ~jawad
  • by Slashdot Cruiser ( 227609 ) on Wednesday April 18, 2001 @10:14AM (#281561) Homepage
    Fortunately, the Unix internal clock works in a manner very similar to the odometer on the Slashdot Cruiser. When you go to trade in your Unix system and step up to Windows, all you have to do is crack open the little block box inside your machine and roll it back several hundred thousand milliseconds.

    Nobody will know the difference save the occasional hidden-camera "consumer protection" reporterette. These people seem to have nothing better to do than spy on semi-honest computer salesman and publicly humiliate them for the crime of trying to feed their families. We could talk about the silliness of having to disclose whether or not your computer had its case straightened after a minor plastic-bender, but that would be a whole nother post....
  • 987656789 would be equally interesting to me


  • I have some REAL news I must share with ya'll...


    NEWS BULLETIN: Poland's worst air disaster occurred today when a small two-seater Cessna 152 plane crash landed into a cemetery early this afternoon in central Poland. Polish search and rescue workers have recovered 826 bodies so far and expect that number to climb as digging continues into the evening.

    Please remove BOOGERS when sending me eMail. Thankyou...

    Sincerely,
  • If you must have the counting dates, you can always look forward to 8/9/01. Frankly, I'm looking forward to the weekend.
  • Then trying to invite people to a Unix rollover party will surely get me put in the geek hall of fame by my non-geek friends. It does coincidentally fall just before my SO's birthday though, so maybe I can get a away with it if I don't tell the the real reason for the party until just before the roll over occurs.

  • If there was ever a reason for geeks to have a picnic, barbecue, and put back some beers...
    a "Billion Seconds of Unix" party sounds like a great idea to me....

    ....ok, actually many other people thought of it first, I've actually heard of a couple of such parties planned in the SF bay area -- you should plan one in your neighborhood!

    - jonathan.


    The Moral Majority was disbanded in 1989
  • I've been having some free time lately, so I've gotten to pondering some questions like these. One of my questions was about why a rational and benevolent deity would allow Survivor II to air on primetime television. The other has to do with the timestamp and a theory of mine.

    You see, neither would a rational and benevolent deity allow the unix timestamp to lap like that. The commotion involved would be significantly worse than the Y2K bug was, because at least with the millennium, people knew to be on the lookout for all sorts of strange behavior (not just computer bugs). But 2038? What kind of date is that? Where's your catchy three-syllable mnemonic for that one?

    So clearly, there has to be another explanation. Mine is that Armegeddon will intercede and prevent this disaster from occurring. A rational and benevolent deity would realize that it would be far better for the universe to be destroyed than for time to cease.

    This poses all sorts of interesting moral, legal, and ethical questions. What should we do about debts that are set to expire after 2038? Should mandatory euthenasia be implemented on all infants born after 2036 so as to avert their agony when the heavens open up and the clarion trumpets of Judgment call forth the arrival of hellfire and brimstone? Will we be able to sublet our cottages in Boca as we've grown accustomed to doing?

    This calls for immediate discussion. A committee of learned professors in each of the relavent disciplines (religion, philosophy, sociology, art history) must convene and solve this problem before it becomes the death of us. We have only thirty seven more years left, so let's make the best of it.
  • by ajs ( 35943 ) <ajs.ajs@com> on Wednesday April 18, 2001 @10:19AM (#281568) Homepage Journal
    So, you have a UNIX timestamp you want to check out? Try Perl on the command-line:

    perl -MPOSIX -le 'print ctime(999999999)'
    perl -MPOSIX -le 'print ctime(987654321)'

    For another timezone, you can just set the TZ environment variable. On the command-line, or in the code:

    perl -MPOSIX -le '$ENV{TZ}="CST";print ctime(200)'

    Actually, because there are historical reasons for ctime supplying a newline, you can drop the "l" from "-le".

  • Shouldn't that be ascending since the numbers are going up? Descending implies the numbers are going down, which they surely are not.
  • My catch 3-syllable acronym for the 2038 bug is....

    Y38

  • by webcrafter ( 175 )
    That should teach to overclockers!!

    Victor

  • Will I be able to view the UNIX times on my Linux box? :)

  • I thought the world ended for the Mayans LONG ago...
  • by Anonymous Coward
    One should really question the sanity in modding this post to "Informative"...
  • I find myself quivering with excitement and anticipation.
  • I'm looking forward to 6969696969... When will THAT happen?
  • by andyh1978 ( 173377 ) on Wednesday April 18, 2001 @10:25AM (#281577) Homepage
    3E08 approx. - Java time fails - (64-bit signed milliseconds from 1970) - A.D. 292,278,994-08-17 Sun 07:12:55.808 GMT
    I knew Java was over-engineered, but this is taking things a bit far. :-p (and possibly being a little optimistic on the popularity of Java over the next 292 million years)
  • Do you know how many time zones are in the Soviet Union?

    Eleven.

    Eleven? [negativland.com]

    It's not even funny. It's ridiculous.

  • by Anonymous Coward
    *snicker* Or, rather "Interesting"... and if either of these posts gets modded up to "Informative" OR "Interesting", I'll be convinced the world is going to end... ;)
  • Why 6/7/89 wasn't good enough for you?
  • by my non-geek friends.

    NON-geek friends? What kind of geek are you?

  • And this was flamebait how? Remember, moderators: it's not just clicking on the little buttons, it's also about reading the post.

  • My car's odomoeter will roll over to 12345 in 93 miles.
  • flamebait!? Did I miss something? OK, who got into my weed again?


    --
  • by J'raxis ( 248192 ) on Wednesday April 18, 2001 @10:29AM (#281585) Homepage
    No module needed:
    perl -le 'print scalar gmtime(999999999)'

    And of course localtime() for your own timezone.

    ...I am the Raxis.

  • Troll? How is this a troll? Someone has some serious issues today


    --
  • Flamebait? Did the moderators eat paint chips this morning or something!? Oh to metamod...


    --
  • Or better yet, Y2-Adams!

    Oh wait, that's 42. Never mind.
  • I don't think Sun was being optimistic at all. I mean afterall they're the dot in dot-com. =)
  • date -d "$((987654321 - $(date +%s))) sec"

    tells you in your local time when that event will happen... (well evntually it is 1 second off if the first date terminates not in the same second as the second... lg mond.

  • 9/9 also happens to be my birthday, so my numbers will be rolling over too. Woooooohooooooo!
  • by Black Parrot ( 19622 ) on Wednesday April 18, 2001 @10:37AM (#281596)
    > Thursday, April 19, 2001 ... the UNIX clock will read 987654321, which is pretty cool.

    OK, but when are we going to get the Slashdot User #987654321 throw-down troll account?

    We went from 100000 to 400000 so fast that I wouldn't expect it to take too much longer.

    --
  • I have something to discuss .. like, why does no one think its fun to know when it happens? Has the market bust turned all us geeks into blinder-wearing profit-seeking business types? How useful is the obfuscated Obfuscated C Code Contest [ioccc.org]? But geeks still seem to dig it ... :) While I may not be staring at 'while (1) { printf("%lu\n", time()); }' when the rollover happens, at least its cool to know we lived the moment! It only happens one in one billion times!

  • Shouldn't that be ascending since the numbers are going up? Descending implies the numbers are going down, which they surely are not.
    And from the article...
    the UNIX clock will read 987654321
    Now can we see the descending numbers? Aren't they pretty?
  • When UNIX makes this mistake it, it's "pretty cool". What would it be if MS-Windows did it?
  • I think the best solution to the year 2038 bug is simply to roll everybody's clock back to the year 1970. Problem solved!

    Besides, disco was so groovy, wasn't it? Yeah, baby, yeah!!

    --

  • This will be the first of two such "significant" events in 2001, the second being 01:46:39 UTC on 2001-09-09, when the clock will read 999999999 (and then of course "roll over" to 1000000000 one second later).

    The other significant thing that will happen on that date is that moderators the world over will be confused, wondering if the moderation guidelines [slashdot.org] actually changed or not.

    (This is in reference to the message moderators get saying "Have you read the Moderation Guidelines [slashdot.org] yet? Updated 9.9". They were updated 9/9/1999, which I guess was such a cool date that they never bothered changing it again, just updated the FAQ [slashdot.org]. Of course, saying "Updated 9.9.99" would be even cooler. Maybe CmdrTaco is waiting for 1.1.11 to update them again, or even 2.2.2222...

  • Not being helpful doesn't make it a troll


    --
  • by ZanshinWedge ( 193324 ) on Wednesday April 18, 2001 @10:48AM (#281612)
    In case you were wondering, unixtime 123456789 occured on
    Thu Nov 29 13:33:09 1973
    (please do not waste mod points on this post, thanks)
  • a little optimistic on the popularity of Java over the next 292 million years

    The part I thought was optimistic was the press release where they promised to have a fix available at least 30,000 years in advance.

  • by abelsson ( 21706 ) on Wednesday April 18, 2001 @10:49AM (#281616) Homepage
    What moron moderated this flamebait?

    In fact, the poster is absolutly correct- Kmail did have exactly the kind of bug he's talking about - a one billion second buffer overrun bug. They issued a patch a few weeks ago.

    read about it here [kde.org]

    -henrik

  • There is another 999999999 rollover problem. Some admin scripts (in BASH, PERL, etc.) assume that the decimal timestamp can be compared as an ASCII string. Unfortunately, 999999999 > 1000000000 in this case, which can cause such scripts to break in subtle or overt ways. For example, if TS1=999999999 and TS2=1000000000, the BASH statement:

    if [ $TS1 ">" $TS2 ]; then

    will evaluate as true.

    -Ed
  • by andyh1978 ( 173377 ) on Wednesday April 18, 2001 @10:53AM (#281622) Homepage
    Then we call it 'Knowledge Base article Q216641 [microsoft.com]' (after quickly working out how long 2**32 milliseconds is)...

    Unfortunately you don't have until 2038 in this case.

  • ...that anybody still using a 32-bit system in four decades deserves what he gets.

    Come on, does that sound so likely? Four decades ago you were lucky to be able to afford all 8 bits in your 8-bit system. And the graph is not a linear one (think Moore here), so four decades from now they'll be laughing at us for working in such a cramped 32-bit address space.

    Solaris has been 64-bit for years now. Same for a number of other Unixes. If somebody is honestly worried about time_t, tell him that a 64-bit time_t can hold more seconds than the probable remaining lifetime of the universe.

    The Divine intent is the same here as it is for folks driving fast in highway construction zones: stupid people deserve what happens to them.

  • Since it's the same number of keystrokes, I didn't bother to introduce scalar context to the Slashdot masses, many of whom are python programmers and would not be comfortable with such flexibility ;-)

    Actually, the fun part is using strftime to pull out all sorts of details like:

    perl -MPOSIX -le 'print strftime("24HR time: %H%M",localtime 999999999)'

    or

    perl -MPOSIX -le 'print strftime("It is on a %A", localtime 999999999)'

    Fun stuff. Perl is your friend.

    (and yes, the Python snipe was humor. I have a deep respect for Python even if ESR is a dink about the "recovered Perl programmer" thing...)
  • Whether or not UNIX will be running before 1970, it still might be useful to store dates before 1970, such as birthdates, etc.

  • by John Whitley ( 6067 ) on Wednesday April 18, 2001 @11:01AM (#281633) Homepage
    I dunno, but that sounds like one of the best excuses for a geek party I've ever heard.

    Heck, that might even be a big enough party to be called a "Conference." ;-)
  • by felipeal ( 177452 ) on Wednesday April 18, 2001 @11:06AM (#281635) Homepage
    ... with the command:

    watch -n 1 date +%s

    or better yet:

    watch -n 1 'echo "The time is near: `date +%s`"'
  • I think the best solution to the year 2038 bug is simply to roll everybody's clock back to the year 1970

    There's a simpler solution: typedef unsigned long time_t; should take us into the 22nd century before we have a problem. (The DJGPP C library already does this.) Another solution is typedef long long time_t; which is on nearly the same order of magnitude as the best estimates for the age of this universe.

  • That would only double the amount of time available, pushing the cutoff to somewhere around 2106. Unix is still being used now, probably will be in 2038, what makes you think it won't be in 2106? ;)

    Also, I don't know if this is just a Perl thing, but dates "past" 2**31-1 (i.e., negative numbers when "signed") seem to be used to represent dates far before 1970.

    For example:
    % perl -le 'print scalar gmtime(2**31)'
    Fri Dec 13 20:45:52 1901
    % perl -le 'print scalar gmtime(2**31+2)'
    Fri Dec 13 20:45:54 1901
    % perl -le 'print scalar gmtime(2**31+2**30)'
    Mon Dec 23 10:22:56 1935

    ...I am the Raxis.

  • Flamebait? Did the moderators eat paint chips this morning or something!?

    Either that or they're upset at the Depend Undergarment remark because it reminded them to change their own.
  • Is there any plan for a *nix wide upgrade to a 64 bit time variable in the next few years? I figure we ought to take care of this now, otherwise the entire *nix community will be mocked by the Windows and Mac communities in the 2030s. Let's just get the upgrade over with and not have to worry about it in the future.

  • Is there any logical reason for the date to be using a signed number as opposed to unsigned?

    I assume that the architects of the system wanted to represent their date of birth. It's the same thing that motivated the Mac OS designers to choose 1904 as the Mac's (unsigned) epoch.

  • Final and decisive proof of my suspicion that some dark cabal - or group of people in desparate need of a life - has been screwing with the moderation system of late.

    I suspect that this will either be modded down to -1 to bury all evidence, or modded up so that they may gloat in their accomplishment.

    Tom Swiss | the infamous tms | http://www.infamous.net/

  • 4/3/2001 and 3/4/2001 - contain all 1st 5 digits. Almost in order, too, though that won't happen until 2100. By which time, I probably won't care.

    3/3/2001 - all sections add up to 3. Also, it's an Odd Day - all non-zero digits are odd, AND all sections are odd, AND all section's digits sum up to odd totals. Since these are also all prime, it was also a Prime Day.

    Trivia Question: When will be the next Prime Millisecond, as measured by RL -and- by the Unix clock?

  • ...is one of the distinguishing characteristics of our technological species. The signifigance is not in the pattern, but in the recognition thereof.


    --
    Scott Robert Ladd
    Master of Complexity
    Destroyer of Order and Chaos

  • maybe you or the cops you do realize it's illegal right?
    No it's not, I can go out and buy some right now, walk over to the police building and offer some to one of the officers, he'll probably smile at me and refuse the offer.
    just because it's illegal in your lame-ass country doesn't mean it's illegal everywhere
    ---
  • it depends on the UNIX. Solaris (sparc), Digital Unix, etc, are all 64 bit already as they run on 64 bit processors.
  • of an access to a website, etc. that has a Unix time counter (if that's even possible)? And what's the significance of the date chosen to be time 0?

    ---
  • Very stupid solution, How will you deal with timestamps from 2037, 2036? they will be times well into the future, so the only solution that will happen will be the use of larger type to represent the number.

  • Since in the next few years 64 bit processors will be coming into the mainstream I think now is the time to start work on fixing the Year 2038 issue. Operating systems will need to be changed to move from 32 to 64 bit word lengths so why not take this oppertunity to switch from 32 bit to 64 bit times on Linux and *BSD (and any other Open Source operating systems you care to mention). A further advantage would be to take make better use of the extra bits and switch to milliseconds since 1970, instead of seconds. This extra precision could be useful for some applications and will still be good till 300,000,000 AD

    This is useable and sensible. I can see this.

    [inserting tongue in cheek]

    But we might not need to worry because of all of the other disasters that are proposed to be happening between now then then, including the end of the Maya Epoch [survive2012.com] (get your Mayan Date TShirt here [halfmoon.org], and the destruction of civilization by asteroids in 2028 (orbit info here [nasa.gov], Seattle Times disinfo here [nwsource.com], commentary here [wisc.edu])

    And, with the crashomatic feature in MS OS software, the world will come to an end well before that when the MS .NET system gets hit with a succesful .NET virus that wipes out lots of data from the hard drives. Of course, it will be a MS email virus, that scans the network for vulnerable files.

    Check out the Vinny the Vampire [eplugz.com] comic strip

  • There is a difference between ">" and -gt in BASH as well. But that doesn't keep people from doing it wrong.

    -Ed
  • I beleive the reason it was not done this way in the first place is so you could do date math.

    I may want to add a negative time increment to the current time to calculate some past date. Adding a signed to an unsigned doesn't always work so well :)

    Changing time_t is not a transparent change. Might as well make it 64bit unsigned, and take the migration penalty once, across the board, as opposed to randomly, on some apps, after you thought they were working for a few months of production use.
  • > 3/3/2001 ... Also, it's an Odd Day - all non-zero digits are odd

    Except for the digit "2".
  • It seems obvious to me that the catchy name for the time_t rollover should be s2G!

  • ... would be 7f6. (As in 0x7f6)
  • 64-bit time_t can hold more seconds than the probable remaining lifetime of the universe.

    "Probable"? What other dead universes are you using for a benchmark? And who is giving odds on these probabilities?
    --

  • Works in hex too (only 4 69's allowed, sorry...):

    >perl -MPOSIX -le 'print ctime(0x69696969)'
    Thu Jan 15 20:25:45 2026
  • that's why I have my Gnome desktop clock displaying UNIX time:
    987628906
    987628907
    987628908
    .
    .
    .
  • As with all Unix and Unix-like operating systems, time and dates represented internally as the number of seconds since the UNIX Epoch, which was the 1st of January 1970 UTC.

    32-bit systems can only store a maximum of 2^31 non-negative seconds (2,147,483,648 seconds or about 68 years). Which means that 32-bit UNIX systems won't be able to process time beyond 19 Jan 2038 at 3:14:07 AM UTC.

    One of the common solutions will be to switch to 64-bit architecture systems that can store a maximium of 2^63 non-negative seconds (9,223,372,036,854,775,808 [9.2 Quintillion] seconds or about 292.27 Billion years), which would be sufficient for quite a long time!

  • Regardless of architecture bits, shouldn't the time_t type be promoted to 64 bits right now, just in case? 32-bit gcc has the 'long long' integer which is just that size.

    And if you wrote code like:

    long mytime;
    time(&mytime);

    Then you deserve the coredump you're going to get. They didn't create types like time_t and size_t without a reason, you know.
  • by Anonymous Coward
    A true geek party would take place at 1073741824 seconds of unix.
  • by Spackler ( 223562 ) on Wednesday April 18, 2001 @12:55PM (#281717) Journal
    I can't wait for the MSNBC story about this one.

    Redmond WA.
    Today Bill Gates announced that all *nix systems will halt with the September 9th coming of the S1B bug. MSNBC recommends that all *nix users switch to Windows XP before it is too late. Steve Balmer was reported to say how amazed he was that *nix could be so short sighted. XP was designed to be S1B compliant right from the start (after installing SP8 due sometime in September). All you Windows users will be kept safe from this, and should not consider going to any rogue operating systems at this time.
  • I guess he didn't update on 1.1.1 because he had a hangover.
  • 1904 was chosen on the Mac because 1900 was not a leap year, and it made the calculation easier.
  • If you haven't checked out the Critical Dates [demon.co.uk] link, it's fascinating (if somewhat repetitve) reading. Just think! Someone actually figured out that, on Tuesday, January 1, 29602, NTFS fails! I'm thinking, if you're stilling using NTFS in 27,000 years, you're probably gonna get what's coming to you.
  • by isomeme ( 177414 ) <cdberry@gmail.com> on Wednesday April 18, 2001 @01:20PM (#281728) Journal
    I dunno, but that sounds like one of the best excuses for a geek party I've ever heard.

    Predicted party song:

    One billion seconds are stored in time_t,

    One billion seconds of time;
    Decrement, post an event,
    Nine hundred ninety-nine million, nine hundred ninety-nine thousand, nine hundred ninety-nine seconds are stored in time_t...

    --

  • Meet your fate in '38!
  • As has been stated elsewhere, Java uses 64bit time on the same epoch, but counts milliseconds instead of seconds. Easy conversion, and we can only measure 292.27 million years.

  • Umm, NTFS4 and NTFS5 fail. The version of NTFS in Win3.51 I believe fails in 2080. Or perhaps it's old Windows code that dies then. Something kills NT3.1-3.51 in 2080, and IIRC, it also kills Win3.11...

    Alex
  • I think this would be a cool idea for a party. The clock rolls over to 1G from 999999999 on the 9th day of the 9th month of the millenium. How cool's that? The 9/9/01 is a Sunday, so it's even kind enough to be on a weekend.

    So pack those beers, grab the munchies, set up a *n?x computer with a BIG display showing the countdown and invite all your appreciative geek friends over. Forget the end of the millenium; the stupids celebrated it a year too early anyway. This is the REAL once-in-a-lifetime event....

    --
  • Hypothesis: God wants us to use 64 bit processors.

    Corollary: Every IA-64 delay makes it more likely that Intel executives will burn in hell.

  • Weird behavior is expected in Windows, so when UNIX does it, everybody just stares in awe...
  • If you like that, take a look at this:

    2E69 approx. - A.D. 1,834,652,618,499,343,590,337,415,746,119,712,509, 834,124,421,548,072,260,582,352,567,003,896-01-25 Sat 17:06:08 GMT, UNIX 256-bit signed time_t fails.

    I'd say that's looking far into the future. =)

    -Cyc

  • So let me get this straight the mightiest country in the world The United States of America is lame?

    yes it is. all this talk about how much freedom you're supposed have when in fact it's not that free at all.
    things like softdrugs and prostitution are illegal, you'll probably say that it's not good for you to use softdrugs or not moral to go to a hooker, but at least I made that decision for myself instead of that the government made it for me.
    I have the freedom to choose and set my own standards, you don't.
    ---
  • Probably Holland.

    yep

    Been there once, very interesting place. Friendly people and travelling is really easy due to the excellent mass transportation systems. I dunno why Amtrak and friends even bother anymore :(

    actually, they're working on making the trains run better according to schedule.
    nowadays you can even get a refund if a train is delayed too long :)
    ---
  • Why don't we move to a 64 bit timestamp?

    My primary occupation is to build ASP applications in PHP - and the 32 bit timestamp is a decided limiting factor.

    So we move to a 64-bit epoch - I don't see any particular problem doing so NOW... but in 37 years it just might be a REAL PROBLEM.

    Why isn't this done? Why don't the kernel developers for Linux just do this, using a slightly different system call? (xtime() instead of time() or whatever)

    A compatability function could SO EASILY be added now, and then software can be written that takes advantage of the extended API...
  • The Java date subsystem was apparently designed by a short sighted individual. Who would use a signed number to represent the date? They could go twice as far into the future if they used it as an unsigned number. After all, time didn't exist before 1970 so it's perfectly okay to just represent it as an unsigned number.

    Sorry, but seeing bad programming practices like this just make be a little upset especially for a supposedly robust system such as Java.
  • by Dwonis ( 52652 ) on Wednesday April 18, 2001 @07:43PM (#281789)
    One billion seconds are stored in time_t,

    time_t is a type, not a variable. You can't store a value in time_t. 8-)
    ------

  • emacs has some weak AI algos installed, such as the famous Eliza doctor program and a collection of Zippy the Pinhead quotes. Someone created a command, M-x psychoanalyze-pinhead which connects one to the other so you can watch the ensuing conversation.

    --

  • I wrote a program which used the current time *2 as a 10-byte IV. When the time rolls over, that program will fail. Why was I doing such a dirty trick? I was trying to squeeze every last byte out of an RC4-based cryptosystem written in Perl.

    The bug was spotted by co-author Jeff Allen, who suggested this fix: *invert* the time with "~". That should keep going until the 32-bit clock runs out in 2038.

    #!/usr/bin/perl -0777i_MUNITION,see_http://ciphersaber.gurus.com
    (pop)?read STDIN,$p,10:print$p= ~time;sub S{@s[$x,$y]=@s[$y,$x]}sub
    Q{$s[($_[0]+=$_[1])%=@s]}@k=unpack'C*',(pop).$p; for$x(@t=@s=0..255){S
    Q$y,$k[$x%@k]+Q$x}$x=$y=0;print map{chr($_^Q S Q$y,Q$x,1)}unpack'C*',<>

    I've had to introduce a space in ";for" to get around Slashdot's random space adding system (bah!) - the minimal version is on my Web pages. Incidentally, the ~ fix didn't save a character, because we still had to leave a space between the = and the ~ since =~ is a distinct Perl token...

    --
  • by GypC ( 7592 )

    Some people theorize that rather than the magnetic polarity of the poles switching, the weight of the icecaps on the poles will cause (and has caused before) the crust of the earth to actually slide over the molten center, as if it were an orange with a loose peel. This would, of course be a highly catastrophic event. Suddenly, the poles are at the equator, the oceans slosh out of their basins, scouring the continents...

    Check out "Footprints of the Gods" by Graham Hancock for more details about this and other far-out but suprisingly well researched and supported theories.

  • Man, if it was 1970 we'd still have to wait 7 or 8 years for disco... where's your music history?

    Sheesh, kids nowdays...

  • In AD 1,834,652,618,499,343,590,337,415,746,119,712,509, 834,124,421,548,072,260,582,352,567,003,896 war was beginning. All your timestamp belong to...nevermind...
  • Not exactly a fair comparison since what you used above produces output like:

    Apr 20, 2001 12:57:09 AM

    Whereas localtime() gives you back a struct! The eqivilent is more like new GregorianCalendar() which gives you a handy calendar for the current locale and the current time (more than you'd get from a struct tm actually!) from which you could extract month/day/year/etc. fields.

    Now, as for outputting that struct in C the same as the Java code you gave, I won't go into that. I will show you two ways to shorten the Java though:

    1) new Date().toString() produces:

    Fri Apr 20 00:57:09 PDT 2001

    (not localized)

    2) If you need the output to be correct for your locale, you can shorten what you had a little:

    DateFormat.getDateTimeInstance().format(new Date()) )

    Which doesn't look so bad, considering all the benefit you get from it!

    The summary - use new Date() instead of Calendar.getInstance().getTime()!!

"It takes all sorts of in & out-door schooling to get adapted to my kind of fooling" - R. Frost

Working...