Unix time: the year 2038 problem

Yah, we spent a lot of time and effort in making sure that nothing broke.

I was working for a company in the electric power business, and we had a y2k war room set up, with people standing by round the clock just in case we hadn't caught everything in all the tests and fixes and patches we'd done to our software... when the first company using our software (in Australia) passed the witching hour without going dark everyone cheered... but we didn't start the party until 24 hours later.

Wasn't that fun? We weren't quite as lucky. We'd spent *mumble* millions on Y2K, but a couple glitches slipped through anyway. None that the public ever had to know about, thank heavens.

It was an interesting management / judgment situation. We could have spent twice as much or more and we'd never have found those specific errors beforehand. If we'd spent half as much... I hate to imagine. Things would have gotten very quiet in a large part of the Americas, and not in a good way.

Well the problem comes when the danger is overstated. Things with Y2K reached near hysterical proportions, with news media declaring everything from your refridgerator, microwave, to the whole power grid would suddenly stop working. Of course I would like to believe people didn't really believe that. There aren't a whole lot of electronics *that* dependent on an accurate date. (and certainly not your microwave or toaster).

Yes, I too always rely on the news media for information about things like health and data processing issues. I mean, what do doctors and programmers know about things like that?

They use img tags, obviously, you moron.

They use img tags, obviously, you idiot. And they don't post pictures in the Scripting Tips forum, because images are disbled here (or so it seems). But here's the img tagged url for anyone who's interested, anyway:

If you use llGetTimestamp it gives the time in Zulu (aka UTC aka GMT) time, so you will have to subtract a few hours to get SL time with attendant rollovers for day/month/year.

Does anyone know how Zulu and SL time interact with respect to daylight savings time? Right now the timeshift is -7 hours, but what happens on (I think the 2nd week of October...)? I have a few functions I wrote for a PIM I'm working on, I'll drop them in a separate thread later on when things are better in-world.

It becomes offset by -8 hours when DST ends. You can check the differences between various time functions to see what the offset is.

I'm using this function to calculate DST difference:

// find out current difference between SL time and DST
integer calculateDST()
{
    integer sl_time = (integer) llGetWallclock();
    integer unix_time = llGetUnixTime() % 86400;
    return unix_time - sl_time;
}

This basically gives me a luxury of leaving worrying about DST to LL. However, if you need to calculate DST for specific dates in the past or in the future, this won't help...

Looks very nice. And way to set that EF person straight LOL.

The watch has two independently adjustable time dials for two different time zones, neither of which actually needs to correspond to SL time. Being a Brit, my first concern with regard to daylight savings time was for UK time (Western European Time, WET; GMT, GMT+1 DST). Unfortunately the rest of the world fails to follow the US in choosing when to switch to or from DST, and I am not certain that everywhere in the GMT-8/GMT-7 time zone follows the US practice, either. Nor can I be certain that anywhere that does do so will continue to do so indefinitely. And, for that matter, nor can I be certain that everybody choosing to display a GMT-7 or GMT-8 time zone is doing so because they wish to display SL time. And, in the southern hemisphere, the direction of the change is the opposite to that in the north.

I have therefore come to the conclusion that to incorporate automatic DST corrections could easily result in errors. Optional reference to an external web site would be ok until the design, or even existence, of that website changed, and having sidestepped the Unix time problem, the watch will last for as long as its SL/LSL operating environment exists. So unless or until I discover a way of overcoming these drawbacks, I shall not include automatic DST correction as a feature, though I do plan to have the watch automatically issue a warning to its user when SL switches to or from DST, based on the comparison with llGetWallclock mentioned in Domichi's post.

But having said that, I suppose it would be possible to include a user-configurable notecard that specified a suitable website URL, the marker tags required to locate the actual time displayed therein, and the format in which that time was displayed. But that would be something to do on a very wet and very boring day in SL, and for a future version of the watch. Getting the colour right is far more important.

(Please forgive me for the increasing verbosity of my posts on this subject; I seem to be using them to think out loud, as it were, and sharing my thoughts with you guys seems to be producing extremely worthwhile results - as well as a lot of unanticipated extra work Thank you all.)

SLT is only good as a DST reference because it's a standard for SL, just like GMT/UTC is only good as a reference because it's considered to be the standard time reference for the real world.

you are right to guess that not all the world follows USA DST (even in the same lateral time zones) there's ~two dozen differing DST offsets around the world, and not all of them are even based on a full hour offset and occur at differing times of the year.

including both SLT and GMT/UTC is about as far as I'd go with an international environment like SL, and leave any local DST tweaking up to the end user (I don't know if there are any modern offsets of less than 30 mins)

A New Zealand friend just mentiond an island group to the east of there that has a 45 minute offset - I've forgotten the name already. Something to do with date changes and DST.

in that case, being able to offset by the minute is probably the way to go