llSLdate()
tracked
Blaise Timtam
llSLdate() similar to llGetDate but not UTC based
Scripts can access UTC date and time, SL time but not date.
Why force us scripters to calculate it from UTC date and a time offset that depends on California summer/winter ?
Log In
SL Feedback
Hello, and thank you for your feature request regarding llSLdate(). This request has been brought up in the past, and we understand the need for a function that provides SL time-based dates directly. We will set this issue to tracked. While we have no estimate on when it may be implemented, please keep an eye on future updates. Your input is valuable, and we appreciate your continued commitment to improving Second Life.
SL Feedback
tracked
Bleuhazenfurfle Resident
I'd rather see proper support for dates and times as a list: [year, month, day, hour, min, sec, hunds, tz, dow] (dow is ignored on input, tz defaults to SLT) — similar to the struct/tuple most languages offer. Combined with a set of functions for converting to and from the formats we know and love, a function to convert between timezones, and have it normalize date and time values out of range — and all this stuff just goes away.
list llUnix2DateTime(integer unixtime);
integer llDateTime2Unix(list datetime);
list llString2DateTime(string timestamp, string format);
string llDateTime2String(list datetime, string format);
list llClock2DateTime(float gettime);
float llDateTime2Clock(list datetime);
list llDateTimeRezone(list datetime, string timezone);
list llGetDateTime(); // same as llS2DT(llGetTimestamp(),TSFMT)
Points of note:
* UnixTime only has second accuracy, but a very useful range, and is easy to work with.
* The script Clock (llGetTime and friends) has better than second accuracy, but a much more limited range.
* Timestamp has all the information, but is an absolute horror to do anything with.
* Any time you feed in a datetime list, the first thing all those functions will do is normalize it (including the timezone which defaults to SLT), and just ignore the dow (Day of Week).
* The format string would be along the lines of the strftime functions that everyone knows and hates (but it does the job, and is familiar), and the corresponding LSL timestamp format would be provided as a constant.
* Leaving the timezone parameter to llDateTimeRezone empty, would have the effect of normalising the datetime without changing it's timezone.
* Timezones are specified as a name (the sim should have a timezone database already?), ±hh:mm, or ±minutes, and normalized to ±minutes format (being the easiest for a script to work with). llDateTime2String should probably convert it to ±hh:mm format (name would be better, but ambiguous, and the script can keep track of and add it on itself).
* This gives you the ability to have a full range date/time (including earlier than 1970, and later than 2038), that you can actually work with in LSL.
* Normalisation means that if you want to know the date next/last fortnight, you just add/subtract 14 from the day, without needing to know how many days are in the month (a value too big or less than 1 just gets rolled through appropriately) — you could also just add or subtract 1209600 from the seconds field if you really wanted to.
* The formatted string commands make LSL timestamp slightly more cumbersome, but let LSL work with external services that represent their date/time differently.
* The script Clock commands take into account the current llGetTime clock reference, and let you set timers and the likes with sub-second accuracy.
* And you should be able to play tricks to look up timezone names (not so much the other way though), retrieve the llGetTime reference, quickly convert ±minutes into ±hh:mm, calculate timezone differences, apply timezone differences, and a variety of other handy things.
Blaise Timtam
Bleuhazenfurfle Resident
Much more that I ask but would be great