New functions: llGetUnixTime2(), llDiffUnixTime2()
tracked
primerib1 Resident
llGetUnixTime()
, because of LSL integer type limitation, can return only 32 bits of epoch seconds. This means that around 19 January 2038, scripts that rely on counting the delta between two unix times will likely fail to function. Some workarounds are possible, but requires a lot of code to implement.Short of introducing a new type,
integer64
, a (probably) much simpler workaround is to implement the following 2 functions:list llGetUnixTime2()
returns a list
whose first member is the higher-order 32 bits of a 64-bit unix epoch, while the second member is the lower-order 32-bits of the same unix epoch. The latter part is a bit tricky because it should be unsigned, so manual arithmetic might be a bit complex; hence, a second function:integer llDiffUnixTime2(list unixtime_a, list unixtime_b)
given two list constructs as returned by llGetUnixTime2()
, the function returns the number of seconds difference according to the rule of a - b
.Alternatively, encode the 64-bit unix time into
string
using Base64. And introduce the functions string llGetUnixTimeB64()
and integer llDiffUnixTimeB64(string a, string b)
. This might use less memory because list
is a complex structure that requires more memory than a string
.Log In
JoyofRLC Acker
Why not just have a function to set an alternative epoch, say 2003 ? ( And a GetEpoch function ).
The suggested solution seems, with respect , to be a bit Heath Robinson.
primerib1 Resident
Because the epoch counter in the underlying OS is already 64-bit. Adding a way to change the epoch means there's additional state to be tracked.
My solution does not need additional state; just 2 function calls, and done. And in the server-side implementation, the first function just takes the OS's epoch counter without needing any manipulation.
If anything, YOUR suggestion is MUCH Heath Robinson, not just "a bit".
Kristy Aurelia
Time to update your scripts to SLua, it is 64bit by default including unix time.
Edit: sarcasm aside - adding new functions will not fix existing scripts, and if the creator is willing to update their scripts to use these new functions, then surely they're willing to swap to SLua, which will bring many other benefits too.
AlettaMondragon Resident
Kristy Aurelia I don't think the SLua code has been released to TPV developers yet.
Kristy Aurelia
AlettaMondragon Resident It will be sometime before 2038
AlettaMondragon Resident
Kristy Aurelia Yes, as always, some of us stay out of the development of new features because of this, and we only get to them when they're already so full of bugs they won't be able to undo the mess.
primerib1 Resident
Kristy Aurelia Sure. IF SLua gets released before they got tired of SL. IF they want to rewrite their scripts in-whole in SLua.
My suggestion allow pretty simple changes: Just modify a few lines of code. No need to translate everything to SLua.
Spidey Linden
marked this post as
tracked
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.