llGetUnixTime, llGetTimestamp, llGetDate, llGetGMTClock, llGetWallclock

We have this lovely function right here, that breaks down the current date and time, in human readable format, down to six decimal points of 'precision' in terms of seconds.

2026-02-07T19:31:56.992713Z

Alongside it, we have llGetUnixTime which will give us the number of seconds since 00:00 hours, Jan 1, 1970.

It's great, it's amazing. But both of these functions only work based on UTC (GMT) time. We have ~similar-ish~ functions that will report the time based on 'seconds since midnight', either in GMT or in Pacific Time (Second Life Time).. the latter is automatically adjusted for Daylight Savings Time (but there is some question as to whether it is DST as reckoned by Unix, by some international consortium, or US/State law).

The math to calculate the 'date' now, (or at any timecode) is absurdly complex, and eats into both script memory and readability for something that should just be a command.

We need a better set of tools.

I'd love to simply plug in something like llGetBetterTimestamp("ET", TRUE) and get back the current time/date for Eastern Time, adjusted for the current (whatever standard is being used) EST/EDT offset.

I'm not sure what the best practices are here.

The problem is that we only have, for example, a couple ways to get 'the date'.. and these are all based on UTC. But there's a lot of hours during the day when UTC's date is just wrong dependent on where you are on the earth. At 7pm tonight (in Pennsylvania), the date returned by llGetTimestamp or llGetDate will be wrong for the next 5 hours. The problem is worse in California, where the date returned is wrong for 8 hours of the day... and don't even get started with Hawaii or Alaska.

Yes, in some cases the math is less cumbersome to 'patch' the values returned, but in many cases it's quite complicated.. particularly if you wanted to get the "day of the week" or something like that.

I feel like this is something that could be fixed with a suite or functions that were purpose built for the task. User Created functions in the 'library' have limited lifespans.. governments change their minds on the dates when Daylight Savings starts and stops too. These things could be updated upstream 'at the source' and then the fixes would propagate to all scripts using them, instead of needing every script writer to fix their code because Arizona decides they're all out on PDT.

Alternatively, some simpler math for determining whether a given location is or isn't "+1" to their official "standard" timezone. llDaylightSavings("USA-PA") returning FALSE or TRUE or something, with a master list of 'names' for each relevant sovereign zone (state, province, etc? USA-AZA, USA-AZB, etc.. )

And then there's the problem of trying to solve "what was the date when the UnixTime was 1237811232?"

..it was Mon Mar 23 2009 12:27:12 GMT.. or Mon Mar 23 2009 08:27:12 GMT-0400 (Eastern Daylight Time) or.. 17 years ago.. according to https://www.unixtimestamp.com/ - I have no idea how accurate that is for EDT/EST on that date.

Support for historical date/day/time calculations would be amazing too.