Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Quickly Descending Unix Timestamp

timothy posted more than 13 years ago | from the sequential-numbers dept.

Unix 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)."

cancel ×

272 comments

Sorry! There are no comments related to the filter you selected.

Are we coming up to an "S1B" bug? (5)

Speare (84249) | more than 13 years ago | (#281557)

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?

How are we going to discuss this?? (2)

FortKnox (169099) | more than 13 years ago | (#281558)

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...

2038? (2)

thrillbert (146343) | more than 13 years ago | (#281559)

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...

This is truly stuff that matters (1)

jawad (15611) | more than 13 years ago | (#281560)

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

It's like an odometer (5)

Slashdot Cruiser (227609) | more than 13 years ago | (#281561)

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....

Palindrome's though common should qualify (1)

Microsift (223381) | more than 13 years ago | (#281562)

987656789 would be equally interesting to me

NEWS FLASH: This is old news. Truely, it is. (1)

AnonymousCowheard (239159) | more than 13 years ago | (#281563)



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,

Re:This is truly (NOT) stuff that matters (1)

sacherjj (7595) | more than 13 years ago | (#281564)

If you must have the counting dates, you can always look forward to 8/9/01. Frankly, I'm looking forward to the weekend.

If calling 1/1/01 the Millenium wasn't geeky enuf (1)

Cy Guy (56083) | more than 13 years ago | (#281565)

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.

Something to Celebrate (1)

hardcorejon (31717) | more than 13 years ago | (#281566)

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

timestamp -- divine intent! (2)

religion major (325437) | more than 13 years ago | (#281567)

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.

Using Perl.... (5)

ajs (35943) | more than 13 years ago | (#281568)

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".

Ascending... (2)

Smirks (115113) | more than 13 years ago | (#281569)

Shouldn't that be ascending since the numbers are going up? Descending implies the numbers are going down, which they surely are not.

Re:timestamp -- divine intent! (1)

SamBeckett (96685) | more than 13 years ago | (#281570)

My catch 3-syllable acronym for the 2038 bug is....

Y38

Ha! (2)

webcrafter (175) | more than 13 years ago | (#281571)

That should teach to overclockers!!

Victor

UNIX timestamps (1)

grub (11606) | more than 13 years ago | (#281572)


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

Re:2038? (2)

sacherjj (7595) | more than 13 years ago | (#281573)

I thought the world ended for the Mayans LONG ago...

Re:timestamp -- divine intent! (1)

Anonymous Coward | more than 13 years ago | (#281574)

One should really question the sanity in modding this post to "Informative"...

Wow (1)

The Bungi (221687) | more than 13 years ago | (#281575)

I find myself quivering with excitement and anticipation.

Yeah, but... (1)

kenthorvath (225950) | more than 13 years ago | (#281576)

I'm looking forward to 6969696969... When will THAT happen?

Java time (5)

andyh1978 (173377) | more than 13 years ago | (#281577)

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)

Time zones (1)

kahuna720 (56586) | more than 13 years ago | (#281578)

Do you know how many time zones are in the Soviet Union?

Eleven.

Eleven? [negativland.com]

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

Re:timestamp -- divine intent! (1)

Anonymous Coward | more than 13 years ago | (#281579)

*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... ;)

Re:This is truly stuff that matters (1)

ivan256 (17499) | more than 13 years ago | (#281580)

Why 6/7/89 wasn't good enough for you?

Re:If calling 1/1/01 the Millenium wasn't geeky en (1)

scotch (102596) | more than 13 years ago | (#281581)

by my non-geek friends.

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

Re:Are we coming up to an "S1B" bug? (1)

ethereal (13958) | more than 13 years ago | (#281582)

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

In other random news: (2)

stilwebm (129567) | more than 13 years ago | (#281583)

My car's odomoeter will roll over to 12345 in 93 miles.

Re:Are we coming up to an "S1B" bug? (1)

silicon_synapse (145470) | more than 13 years ago | (#281584)

flamebait!? Did I miss something? OK, who got into my weed again?


--

Look, ma, no modules! (5)

J'raxis (248192) | more than 13 years ago | (#281585)

No module needed:
perl -le 'print scalar gmtime(999999999)'

And of course localtime() for your own timezone.

...I am the Raxis.

Re:How are we going to discuss this?? (2)

silicon_synapse (145470) | more than 13 years ago | (#281586)

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


--

Re:2038? (1)

silicon_synapse (145470) | more than 13 years ago | (#281587)

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


--

Re:timestamp -- divine intent! (1)

jayhawk88 (160512) | more than 13 years ago | (#281588)

Or better yet, Y2-Adams!

Oh wait, that's 42. Never mind.

Re:Java time (1)

ryuspeed (443132) | more than 13 years ago | (#281589)

I don't think Sun was being optimistic at all. I mean afterall they're the dot in dot-com. =)

Re:number sequences (1)

don_carnage (145494) | more than 13 years ago | (#281590)

ahhh...what amuses a geek. :^)
--

others I've missed (1)

cornflux (168139) | more than 13 years ago | (#281591)

Damn, I can't believe I missed 696969696! Seeing 31337 would have been cool, too. Uhm, yeah.

Re:timestamp -- divine intent! (1)

RinkRat (15800) | more than 13 years ago | (#281592)

I'm patenting/trademarking/copyrighting/whatever that right now! You lose, sucka!

8^) Ahh, US businesses... What evil *won't* they do?

Using Shell and GNU date (2)

dermond (33903) | more than 13 years ago | (#281593)

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.

Re:How are we going to discuss this?? (1)

Steeltoe (98226) | more than 13 years ago | (#281594)

Well... You ARE discussing it at this very moment, aren't you? So I guess we don't really need any great stories ;-)

- Steeltoe

Its just a birthday celebration of time! (2)

dattaway (3088) | more than 13 years ago | (#281595)

9/9 also happens to be my birthday, so my numbers will be rolling over too. Woooooohooooooo!

But tell us... (3)

Black Parrot (19622) | more than 13 years ago | (#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.

--

something to discuss (2)

SirSlud (67381) | more than 13 years ago | (#281597)

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!

Re:Ascending... (2)

andyh1978 (173377) | more than 13 years ago | (#281598)

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?

Re:This is truly stuff that matters (1)

Ironix (165274) | more than 13 years ago | (#281599)

Damn!

I was born on June 4th, 1978 @ 12:35

Hmm.....nice wording (2)

RiotXIX (230569) | more than 13 years ago | (#281600)

When UNIX makes this mistake it, it's "pretty cool". What would it be if MS-Windows did it?

Re:Using Perl.... (1)

gupta (413494) | more than 13 years ago | (#281601)

thanks for these commands. there is always a thing to learn everyday.

Re:timestamp -- divine intent! (1)

Black Parrot (19622) | more than 13 years ago | (#281602)

> Y38

Not to be confused with 38@Y, which is the title of a p()rn() flick.

Erm... no pun intended with the "flick" part.

--

Re:Are we coming up to an "S1B" bug? (1)

altair1 (71744) | more than 13 years ago | (#281603)


What is there to format? The time is just an integer which is converted to readable formats by math operations. And nobody has to do that sort of thing by hand anyhow. Plenty of library routines exist for converting time to other formats.

Descending? (1)

tycage (96002) | more than 13 years ago | (#281604)

In my universe, time is flowing forward. --Ty

Re:Yeah, but... (1)

MeltyMan (262145) | more than 13 years ago | (#281605)

According to the SCO box here at work, Wed Aug 28 22:59:37 1918... :)

signed? (1)

Leto-II (1509) | more than 13 years ago | (#281606)

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

Did the great Unix engineers think we'd find a method of time travel and take Unix back to before the epoch?

Fear my low SlashID! (bidding starts at $500)

Solution to 2038 bug (2)

DeadVulcan (182139) | more than 13 years ago | (#281607)

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!!

--

Other significant happenings on that date... (2)

JWhitlock (201845) | more than 13 years ago | (#281608)

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...

Re:illegalities (1)

silicon_synapse (145470) | more than 13 years ago | (#281609)

So because it's illegal, it's automatically wrong?


--

Re:Ascending... (1)

Smirks (115113) | more than 13 years ago | (#281610)

Yes, however, on the grand scale they are going up. ;)

Re:assistance (2)

silicon_synapse (145470) | more than 13 years ago | (#281611)

Not being helpful doesn't make it a troll


--

Also..... (5)

ZanshinWedge (193324) | more than 13 years ago | (#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)

Re:Java time (2)

stripes (3681) | more than 13 years ago | (#281613)

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.

Re:How are we going to discuss this?? (1)

3am (314579) | more than 13 years ago | (#281614)

i agree totally, this didn't deserve to be a full fledged article. this is a interesting tidbit at best.

Re:timestamp -- divine intent! (1)

kennylives (27274) | more than 13 years ago | (#281615)

You see, neither would a rational and benevolent deity allow the unix timestamp to lap like that.

I think it's probably time for you to stop playing Black & White for a little while...

Re:Are we coming up to an "S1B" bug? (4)

abelsson (21706) | more than 13 years ago | (#281616)

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

Re:Palindrome's though common should qualify (1)

travisd (35242) | more than 13 years ago | (#281617)

That's tomorrow actually.

bash-2.03$ perl -MPOSIX -le 'print ctime(987656789)'
Thu Apr 19 01:06:29 2001

Re:Java time (1)

Anders1 (443473) | more than 13 years ago | (#281618)

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)

It's better to over-engineer than to under-engineer. 2038 isn't too far away; things would be a whole lot nicer if everyone had used 64-bit timestamps. And I don't think anyone's going to miss the extra 4 bytes of storage needed.

Re:Are we coming up to an "S1B" bug? (5)

edhall (10025) | more than 13 years ago | (#281619)

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

Fix for 2038 (1)

hey (83763) | more than 13 years ago | (#281620)

Why not just change:

typedef long int __time_t;

into:

typedef unsigned long int __time_t;

Re:Java time (1)

otis wildflower (4889) | more than 13 years ago | (#281621)

Too bad date/time manipulation in Java is such a steaming pile of shite.. :(

Your Working Boy,
- Otis (GAIM: OtisWild)

Re:Hmm.....nice wording (3)

andyh1978 (173377) | more than 13 years ago | (#281622)

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.

The Divine intention is pretty clearly... (2)

devphil (51341) | more than 13 years ago | (#281623)


...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.

Re:2038? (1)

dj_flux (66385) | more than 13 years ago | (#281624)

The Mayan calendar ends on December 21 2012. *shrug [tripod.com] *

Re:Look, ma, no modules! (2)

ajs (35943) | more than 13 years ago | (#281625)

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...)

Poster needs to take some Math and Comp Sci (1)

loki2eng (104976) | more than 13 years ago | (#281626)

These numbers are arbitrary. This is a smaller version of the same kind of superstition that gives rise to believing in Nostradamus and other hooey.

Wow (1)

AME (49105) | more than 13 years ago | (#281627)

Never thought I'd see a link to John Stockton's website in a Slashdot story. Talk about world's colliding!

--

Re:Solution to 2038 bug (1)

Anders1 (443473) | more than 13 years ago | (#281628)

I think the best solution to the year 2038 bug is simply to roll everybody's clock back to the year 1970. Problem solved!

That will probably happen anyway, whether you like it or not! :-)

Using date (Re:Using Perl....) (1)

MavEtJu (241979) | more than 13 years ago | (#281629)

On FreeBSD:
[~] edwin@p6>date -r 987654321
Thu Apr 19 06:25:21 CEST 2001


Re:Descending? (1)

spankfish (167192) | more than 13 years ago | (#281630)

In my universe, time is flowing forward. --Ty

That's your perception, and it's interesting. Different cultures have widely varying perceptions of "time". Most people in Western cultures tend to view time as an axis we are walking along in a forwards direction.

Some tribal societies perceive time in the completely reverse way, e.g. they will view time as a river, and they are on the shore looking in the direction the river is flowing to, and say that if they want to postpone something, they'll put it back, not forward as Westerners would.

Bugger. That confused me.

--

It's Okay! There's a solution. (1)

neo (4625) | more than 13 years ago | (#281631)

Article on Chronology [saturdaynight.ca]

Luckily we have more time. It's only the year 936AD and as soon as we realize it, we'll set all the unix clocks back.

Re:signed? (2)

Anders1 (443473) | more than 13 years ago | (#281632)

Whether or not UNIX will be running before 1970, it still might be useful to store dates before 1970, such as birthdates, etc.

"One Billion Seconds of Unix" (4)

John Whitley (6067) | more than 13 years ago | (#281633)

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." ;-)

UNIX title is Misleading -- Think ANSI C... (1)

TimeHorse (6545) | more than 13 years ago | (#281634)

ANSI C defined the epoch as 00:00:00 UTC 1 January 1970 C.E. and defines the set of functions in the time.h library as returning a structure -- among others -- as time_t, defined as a long, which is 32-bits, and is the number of seconds since the epoch. The problem is of course that a 32-bit number can only store so-many seconds, so that come Jan 2038, when just over 2 billion (2e+9) seconds have passed, we go into negative numbers, perhaps around 1902? :) Anyway, so all you are saying is if we do a "time(NULL)" the time_t, or long, returned when converted to decimal will be "987654321" and that we are rapidly approaching "1000000000" and expect "1234567890" sometime later this decade. Okay, I see. Now as for any other language which uses the same time structure, keep in mind that it was probably compiled, if not directly, than inderectly under C at some point (even if it is now 'self-compiling' as C is. So let's give credit where credit is due, people! Long live ANSI C!!!

Be Seeing You,

A C++ programmer, really!

Watch it live... (3)

felipeal (177452) | more than 13 years ago | (#281635)

... with the command:

watch -n 1 date +%s

or better yet:

watch -n 1 'echo "The time is near: `date +%s`"'

Simpler solutions: 64-bit or unsigned (2)

yerricde (125198) | more than 13 years ago | (#281636)

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.

2038 - Now is the time to start work (1)

sjmurdoch (193425) | more than 13 years ago | (#281637)

I don't know if there are already plans about the 2038 problem but here are my thoughts on it.

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).

As well as rewiting the operating systems, applications may need work for the IA64 chips. While this is being done why not make the programs compatible with both 64 bit and 32 bit timestamps?

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.

Any comments?

--
Steven Murdoch.

Unsigned long (2)

J'raxis (248192) | more than 13 years ago | (#281638)

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.

Re:2038? (2)

thrillbert (146343) | more than 13 years ago | (#281639)

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.

Re:something to discuss (1)

poot_rootbeer (188613) | more than 13 years ago | (#281640)

EVERY moment happens only once! There is nothing that makes 987,654,321 seconds since epoch any more significant than any other second in the history of ever, except for the human brain's tendency to pick patterns out of noise.

Ok, maybe I'm looking too far into the future, but (2)

proxima (165692) | more than 13 years ago | (#281641)

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.

Date of birth (2)

yerricde (125198) | more than 13 years ago | (#281642)

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.

Re:Fix for 2038 (1)

Black And Decker (413435) | more than 13 years ago | (#281643)

That's quite simple.

The negative numbers are used to represent the years prior to 1970.

Re:timestamp -- divine intent! (1)

fatphil (181876) | more than 13 years ago | (#281644)

U2G (Unix 2 Gig?)


--

Interesting Moments (1)

nquartz (263550) | more than 13 years ago | (#281645)

I was alone in my office while I watched the clock roll to 11:11 am. That was November 11, 1999. The full time stamp to observants would have read 11:11:1999. Observing that moment, I thought, was cool.

Then again, I'm a geek.

Re:timestamp -- divine intent! (1)

haruharaharu (443975) | more than 13 years ago | (#281646)

One of my questions was about why a rational and benevolent deity would allow Survivor II to air on primetime television

This, more than anything, has eroded my faith in God

Re:"One Billion Seconds of Unix" (1)

felipeal (177452) | more than 13 years ago | (#281647)

Someone once mentioned that on the SVLUG list, as it is also close to the Linux 10th birthday, in August.

Re:Look, ma, no modules! (1)

J'raxis (248192) | more than 13 years ago | (#281648)

Ah, yes, strftime, probably my favorite POSIX module function. I always use strftime when I want a date output in scripts, because I prefer the ISO8601 "largest-to-smallest" format, e.g. 2001-04-18 16:18:10 (%Y-%m-%d %H:%M:%S). But when I'm doing Perl one-liners I prefer to be lazy and not think of %entities, satisfied with the usual Unix date string ("asctime"? I think...).

Of course, strftime's got nothing on PHP's date() [php.net] function... :)

Oh, and without scalar context, you get a mess ("54222018310131070") -- not to mention list context is very bad for you [slashdot.org] .

...I am the Raxis.

Re:timestamp -- divine intent! (2)

Mr. Slippery (47854) | more than 13 years ago | (#281649)

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/

Re:If calling 1/1/01 the Millenium wasn't geeky en (1)

Liquid(TJ) (318258) | more than 13 years ago | (#281650)

I have a feeling that if you call this the "real reason for your SO's birthday party, you'll just be celebrating getting you ass kicked...

Other significant dates, albeit "RL"... (2)

jd (1658) | more than 13 years ago | (#281651)

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?

Re: The only reason for time.. (1)

r_j_prahad (309298) | more than 13 years ago | (#281652)

Actually, everything DOES happen all at once. Your brain only simulates for you the passage of time so that it is not completely overwhelmed. You will already be dead before you finish reading this, of course, and yet unborn as well. Requiescat in peace and happy birthday.

Picking patterns out of noise... (2)

ChaoticCoyote (195677) | more than 13 years ago | (#281653)

...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

Re:Descending? (1)

tycage (96002) | more than 13 years ago | (#281654)

I'm sorry, did I confuse you? Do I need to raise my hand when I make a joke?

*raises hand*

--Ty

Re:Unsigned long (1)

fatphil (181876) | more than 13 years ago | (#281655)

2038 is +2G
1970 is zero
1901 is -2G

What's the problem?

FP.
--

Really? (1)

tycage (96002) | more than 13 years ago | (#281657)

I honestly did not know this.

That's what I like about /. I make an off the cuff smartass comment, and I actually end up learning something.

--Ty
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>