Unix time: the year 2038 problem

On Tuesday, 19 January 2038, at 03:14:07 Unix time will run out of bits and cycle round to -1.

I am making a wristwatch that uses Unix time as its basis. I have made no allowance in my code for this problem (the watch includes alarms, countdowns, a timer and has day and date displays that would be affected, along with the usual second, minute and hour hands).

My question is, should I give a damn?

That kinda depends on whether (a) you will be around in 2038, (b) SL will still be around, and (c) LSL will still be a viable language at that point. Personally, I'll be 94 that year and unlikely to care whether a watch I buy from you now is still working right.

depends on whether you are allowing dates nearly 30 years from now to be set.... you could limit them, use some of the perpetual calendar code instead (which should be good for a few millenia in lsl), or chalk it up as anyone silly enough to push dates that far in advance deserves what they get =)

we are after all talking about a watch, and not galactic change map projection.

People keep telling me the world will end in 2012 anyway. Something to do with the Mayan Calendar.

Goblins will steal all your cookies in the year 2012 so yah... The world will end!

What about time travel? You have to take time travel into consideration of coding. So not only you have to code for after 2038 but also for 1,000,000 BC.

Sure! Since you have the opportunity to re-write the code now, on Aug. 28, 2009, change you logic to assume anything "under" Jan. 1, 2009 (or some other convenient date that's before today) uses the roll-over date as its epoc. That'll gain you a few decades, at least. No problem

Or, retrieve the date in textual form, extract the year, and use that to determine whether (and how many times) the counter has rolled over. You can probably assume SL itself will be fixed to return a correct date string, at least. Who knows what they'll do to UNIX time by then, so we're still making some risky assumptions, but....

I know this is very sad, but I am actually tempted to try something like that. My first thought was to make a 64 bit emulator for the Unix time arithmetic, but I realise that that would merely postpone the problem rather than solve it. But it would be a nice touch to be able to spuriously advertise (yeah, I know: split infinitve) the watch as being year 2038 compliant, much in the same way as some sellers mark their stuff as "mono compiled".

The watch will be free if I ever manage to satisfy myself that it's in a fit state to unleash on the public, which will be sometime around Tuesday, 19 January 2038, at 03:14:06, at the current rate of progress

And omg! I haven't even considered whether I need to account for leap seconds in my code! I must read up on Unix time in more detail.

Build the update system into your product and delay that decision for 29 years. On the other hand, maybe you should fix it right now; having to fix the code you wrote 30 years ago will require quite an remembrance effort!

On a more serious note, I'm using llGetUnixTime() as well and I've taken this into account, not because I think my product will live that long, but simply because if was fun. If someone does keep using my product 30 years from now, he'll get a small easter egg and a thank-you note.

I don't think it's so unreasonable to think LSL will be used 30 years from now; TCP/IP in the form we use today is almost 30 years old. SMTP dates back to 1980 as well. While I certainly hope we'll get to use another programming languages with SL, since LSL VM works with Mono bytecode, I see no reason why LL wouldn't support it almost indefinitely.

Of all the people who made predictions about the end of the world, who is to say the Mayan's got it right? They didn't see the Conquistadors coming and that's who obliterated them. Anyway it was my understanding, thats just when their calendar ends, not when the world ends. It just means it's time to call up the stone mason and order a new calendar.

Anyway If anyone is really confident the world is coming to an end and knows the date and it's within our lifetimes, well I'm willing to bet them any sum of money it isn't going to be the end of the world. Heck I'll even give 1:100 payout.

But the thing that gets me is this: people are worrying about dieing, you only die once, and compared to the rest of your life, it's pretty quick and a minor part. It's the rest of your life you should be worried about. Nobody ends up on their death bed thinking "I wish I had spent one extra day thinking and worrying about this day" Ok so maybe that isn't true, death is a mighty deterrent from doing stupid things (like base jumping, reflecting on the danger prior to engaging it can save your life). But you get my point. If it is out of your control, don't waste your time on it.

Now onto the topic:
2038, do we care?
It turns out to be the wrong question. The right question is: Is there anything we can do about it? While it is possible to hack something together that would work, the important thing is: It would be a hack. LL has chosen so far not to care about this problem, which pretty much ties our hands.

In the 70's and 80's nobody cared about the year 2000. It was more than a quarter century away, they figured nobody would be so daft as to be running the same old legacy code. In this day and age, you get plowed under if you aren't agile enough as a company, old code is a liability, it contains old assumptions that may no longer be true.

Personally I can't wait until 2040 when the old Mac time format overflows. I can just imagine the woeful wails of the enthusiasts now.

I can save you the trouble since I went through the documentation myself. llGetUnixTime() actually uses Unix time, not UTC. Unix time, unlike UTC, doesn't use leap seconds, so it's a bit less precise but easier to work with.

http://en.wikipedia.org/wiki/Unix_time

JIRA: llGetUTCTime

I don't think our hands are tied. For example, since I use Unix time to calculate differences between two times, and don't save times for more than 24 hours. Simple solution is to go out of order for the first 24 hours after Unix time flips; but I can also compensate for high/low values of Unix time.

So, it's just another simple limitation in LSL land which needs a workaround.

Clear me some space in your PM's Strife!

Hope leg is feeling better.

Actually, you should just use llGetTimestamp(). It returns a string AND should have enough resolution to fit whatever needs you have, so long as the text processing isn't too costly.... Truth is, most systems (e.g. databases) have a limit on date and time stamps too, but depending on how they deliver the results to you, it may be abstracted enough that we don't have to care about it at the API level. So just trust they'll fix whatever issues may arise behind the scenes and be happy.

Hmm, you have a point. I did start off using that but quickly switched to Unix time for ease of use and speed of calculation. But since then I've also farmed a lot of the main timer loop work out to the individual hands and indicators (so they can move together, all at once rather than one after the other), so there should be plenty of slack there to extract the time elements from the timestamp and to calculate a psuedo-Unix time integer with a variable base time... I already use just two constants for the Unix time base: 1970 and 3 (Unix time began on a Thursday) and changing those every decade or so wouldn't be a problem... And this would take those leap seconds into account (wouldn't it?)...

I'd need to be careful to handle timer (a stopwatch, but without sub-second precision, ludicrous to even think about that in the SL/LSL environment) and tachymeter measurements, and countdowns (to alarms, and also an excuse to run some hands backwards now and then) that spanned a base time update, and/or a leap second, properly...

And virtually nothing else would need to be changed...

This sounds too good to be true. What have I missed?

lol. Thanks Hewee, you seem to have turned what was meant to be a bit of a joke into a viable proposition

/me starts chanting to herself, "I will not be tempted to try to do anything at all with llGetTimestamp's sub-second precision; the accuracy just ain't there. I will not be tempted..."

Would this qualify as an elegant solution, or is it still just a hack?

Beats me. I suppose it might be called elegant given our level of access to things like machine time. It at least allows us to put some of the burden on LL rather than creating really hacky hacks.

you could use httprequest() to poll the NIST Internet Time server ;p Now that would be elegant.

http://tf.nist.gov/timefreq/service/its.htm

(in truth you can't, because they use non-standard ports )

that's one funny bet... if the world ends you don't have to pay out otherwise you collect.... (I want to say it's better than the 40 random people of which two will share a birthday, bet... except it's bit transparent)

PS @ others:
if you read up though, the mayans didn't predict the end of the world, just the end of an age...

PPS:
you're releasing it as a freebie? oh hell I'd say let it go as is, or at worst add some limit code)

It has my name on it; it must be as good as I can make it. Besides, I will use it too, and I demand nothing but the best

PS I so wish there was some way I could upload a picture here. Even though I say so myself, it really does look impressive, and I do believe those looks deserve the functionality to go with them. Is there anything I can do to try to get the forum software to behave for a minute or two? What do the people who can upload pictures here do that I'm not doing?

Hmm. From my cursory reading of /usr/include/bits/types.h and -/typesizes.h, time_t is word size. Not that this helps stored 32-bit values (such as alarms preset for 2039), but don't we suppose that by 2038 a 32-bit architecture will be as quaint as nibbles?

So... just sell the watch with Modify perm on the prims, so folks can recompile gramp's pocketwatch?

time_t gets stored on disk and sent over the net so even on 64 bit operating systems it's still 32 bits because that's the size of the inherited structures.

A new type, longtime_t perhaps, will need to be introduced. So it won't "just happen".

Can not imagine the commands or language we will be using with the Direct Neural Interface architecture by that point. Can not wait to try my hand at hacking it thou

Chances are, everything made in SL today will be obsolete in 10 years, so it is probably a moot point.

Even still, I would expect that, in the next 28 years, they will either have a workaround (extending integer types to 64 bits), or will have a migration to LSL3 (or 4/5/6/7/etc) which will obviate the issue.

That said, Y2K was a non-event, for the most part. Some stuff broke, but most stuff kept right on going.

If you are doing something which requires long-term persistence for time, don't use Unix time, use a more absolute time reference. Problem solved.

This is a deprssingly common sequence of events: a danger is seen, a warning is issued, the warning is acted upon and steps are taken to avoid the danger, and thus the danger is avoided. Obviously, therefore, there was no need to issue a warning in the first place.