Talk:LlGetUnixTime

Is there any word on what time-zone the system sits on? Is the system clock set to UTC? PST? MST? CST? EST? Is the clock consistent throughout SL or is it dependent upon which server a particular region sits on? When subtracting a timestamp set to pacific time from the llGetUnixTime() result on RPS Island I receive a result 3 hours 'short' of expectations ... seeming to indicate that, at least at RPS Island, the llGetUnixTime is not based on PST. Kenn Nilsson 20:53, 6 June 2009 (UTC)

*sigh* llGetUnixTime is the number of seconds since Jan 1, 1970  UTC. It doesn't matter what time zone the simulator is in, the return of llGetUnixTime would be the same regardless. As to what the other time functions return, please refer to those specific articles. -- Strife ^{(talk|contribs)} 00:21, 7 June 2009 (UTC)

TY for the answer ... seems I missed the "UTC" timezone indication on the original wiki post. The results still do not correlate (as UTC time compared against PST time would result in a 7 or 8 hour difference - dependent upon DST settings - not a 3 hour difference), but I do now have an assumed constant that I can work from. Thank you. Kenn Nilsson 01:06, 7 June 2009 (UTC)

What is the function you are comparing it against and in what region are you working in? It sounds like the simulators time may be mis configured (or it's located in Argentina). -- Strife ^{(talk|contribs)} 16:10, 7 June 2009 (UTC)

2038 Bug

I wonder if what'll happen in practice, is that environments like SL will move on to 64-bit platforms before 2038, so there won't be a 32-bit wrap problem? It's not inherently a Unix Time limitation. Omei Qunhua 16:14, 12 December 2013 (PST)

I'd like to say that LL will instead of bolting 64bit ints onto the language would replace LSL with something like C#. But the cynic in me says we will be using the same language for the next 10 years (my inner cynic has had close to *cringe* 10 years of training) and only then will they bolt on 64-bit math. Ok Ok that is probably way to cynical. I doubt they will be making 32bit compatible chips in 10 years... but maybe they will. Who knows. I will try to remain optimistic and maybe this will be just the issue to get them to modernize LSL. Maybe I should have waited until 2020, SL would have been half the way there. I'm so not use to thinking in such glacier terms. I must be getting old. -- Strife ^{(talk|contribs)} 19:50, 12 December 2013 (PST)

Sim hosts are running on 64 bit Linux and the sim source was made 64 bit clean a long time ago. Sims are still being compiled to 32 bits because, worst case, script memory use doubles under 64 bits. So we're waiting for old server hardware to keel over and die before they try it again. It should not be too hard to slap on 64 bit time functions after that hurdle. --ObviousAltIsObvious Resident 10:57, 13 December 2013 (PST)

That is cool! Faith renewed! My gripes with LSL are minor really. And doing away with the language would really take some of the fun out of SL. A virtual world needs it's own programming language, it's part of the experience, part of the immersion. You do not get into SL for more of reality, which is what a real programming language would bring to SL. -- Strife ^{(talk|contribs)} 21:21, 13 December 2013 (PST)

I so agree with you, Strife. I *love* the simplicity and even quirkiness of LSL. Maybe because I was brought up with primitive computers and languages since I first worked on a Ferranti Pegasus with Autocode in 1961. So much fun is in overcoming the challenges, finding what works best, fastest, and shortest. I still find it amazing what a few lines of LSL can achieve. Omei Qunhua 04:55, 14 December 2013 (PST)