Difference between revisions of "Talk:LlGetUnixTime"
Omei Qunhua (talk | contribs) m (2038 bug) |
|||
| Line 10: | Line 10: | ||
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. [[User:Omei Qunhua|Omei Qunhua]] 16:14, 12 December 2013 (PST) | 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. [[User:Omei Qunhua|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. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 19:50, 12 December 2013 (PST) | |||
Revision as of 19:50, 12 December 2013
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)