Using GMT time in SL
tracked
Hanna Stardust
Using GMT instead in SL, to make it easier to relate to (for those living outside the US) and daylight saving time at different times in different countries makes it even more confusing.
We use English so that everyone can understand it, and using GMT (without daylight saving time) is also something everyone can relate to when it comes to time.
Alternatively, some function where you can translate SL time to our own time zones or at least to/from GMT.
Log In
Quinn Elara
+1 for changing to UTC
Furious Soup
Supported, but it must be UTC, not GMT.
Signal Linden
Merged in a post:
Change SLT to UTC (stop using P?T)
primerib1 Resident
Because SLT is pegged to P?T (PST or PDT depends on date), the time change during the DST-nonsense transition period often confuses people.
This is especially bothersome because the whole world can't agree on when to start DST-nonsense and when to end DST-nonsense.
Besides, DST is an archaic artificial construct that today serves no purpose, and in fact results in higher energy usage, increased accident rate (especially in the week following transition), and people missing important events because they forgot / not aware of the nonsensical clock changes just because some people in the steam age thought so.
My suggestion -- no, PETITION -- is to change over SLT to UTC once and for all.
Benefits:
- UTC is monotonic, it does not have DST-nonsense. There will no longer be a need to move in-world clocks forward/backward forever.
- ALL timezones in the world are offseted against UTC. Just look up the definition of one's own (currently active) timezone, and do a single calculation (apply the UTC offset). Greatly simplifies mapping SLT to one's local time. (Currently, I have to first find out if SLT is using PST or PDT, then I have to find P?T's offset from UTC, add my own offset, then add everything to find out my time.)
- If you're using Linux servers (which I'm certainyou are), then the server time matches with SLT time; if there's a report that "something happened around 14:12 SLT" it will be very easy to find events with UTC timestamps of 14:12:xx
- In case LL moved their HQ, say, to Europe, there will be no need to change SLT to <insert European timezone here>; the time is already in UTC, and that applies universally.
In addition, UTC is ahead of SLT. So during Change Day, there won't be any "Double Timestamp" in the logs; the clock jumps forward by 7 or 8 hours (depending on whether DST-nonsense is in effect or not at the time of Change, respectively).
Of course there will be the annoyance of changing scheduled time of regular events, but this will happen only ONCE and afterwards there will no longer be any need to change.
Nyx Onyx
As I have been commenting on Discord and elsewhere: I don't care about the timezone, but SLT should really not be doing DST. DST means that people in places outside of the pegged timezone will have to adapt four times per year if they themselves do DST and on a different time or even date. Other than for the people in PST, what's the pros for keeping DST for SLT, rather than keep its offset to UTC throughout the year? And ugh for all the acronyms.... https://www.youtube.com/watch?v=ssZNaqUDZXk
AndreasDarth Resident
UTC is king, you can convert your client time or scripts to any timezone you like based on varous settings/conversion. UTC doesn't have DST so the time is consistent, only inconsistency is RL and location you're based in.
The double timestamp in the logs is real thing. Twice per year you have situtation where you have "no backup" coz TZ skipped an hour and situation where you have two backups where at least on is corrupted.
Reason you must adjust you calendars is simply because during the DST the Europe (end of March) and USA (beginning of March). And other reagions can change their DST as their local government decides. So having a time which is not affected by DST is win for everyone. Yes once it will be annoying, but it only will be annoying once, not twice per year and every year.
Using TZ which is not affected by DST is essential and RL just won't bother us.
primerib1 Resident
AndreasDarth Resident Truth be told, scripts that might break if time is not monotonic all have been using
llGetTimestamp()
which, surprise suprise, already
returns a UTC timestamp in nice ISO8601 formatting.So yeah. Scripters already know of the importance of monotonic time.
jackiewallace Resident
I can't support this idea. Besides, understanding time and time zones is part of elementary school education.
primerib1 Resident
jackiewallace Resident Switching to UTC does not mean one no longer need to understand timezone.
In fact, switching to UTC means that people are educated that there's a singular, internationally-accepted way of signifying timezones: UTC Offset.
jackiewallace Resident
primerib1 Resident The viewer is open source, everybody can create a UTC based viewer, and everybody can use that time zone what they want. I will use SLT. LOL
primerib1 Resident
jackiewallace Resident It is not meant for display for just one person only.
You can't schedule an event "13:00 my viewer time" because everyone will have different time displaying on their viewer.
And that is the reason for this petition of wanting a strictly-monotonic, no "spring forward fall backward" nonsense being applied to the in-world clock.
And if one is already going to do away with DST, why not decouple completely from localized timezone and use an internationally-accepted standard for indicating a "point in time", which is the UTC?
Rathgrith027 Resident
I firmly oppose this measure.
Point 1 is likely not to be relevant in the near future as even with the.. questionable competency and legitimacy of the US Government, we may be doing away with DST permanently.
Point 3 is irrelevant because they likely use internal tools to convert those times or are already well familiar with converting them.
Point 4 will likely never happen. Linden Lab's ORBAT is too deeply engrained in the US that it would only happen as an act of desperate survival for the company, that even with political affairs, will not happen.
Doing this would upend our community's events system, throw planned events out of whack and require us to adjust to an entirely different time system.
primerib1 Resident
Rathgrith027 Resident "throw planned events out of whack and require us to adjust to an entirely different time system."
But that will happen ONLY ONCE, and never again.
Currently, depending on the event organizer's RL location, planned events might have to be adjusted FOUR TIMES IN ONE YEAR:
- Once when either of California or the EO's implement DST
- Once when both implement DST
- Once when one of them stops DST
- Once when both of them stops DST
Every. Year. Four. Times.
My proposal changes the time ONCE FOR EVER.
If people can -- and they do -- adjust event times FOUR TIMES A YEAR, they can -- and will -- adjust event times ONCE AND NEVER AGAIN.
At the worst, to sync up with the organizer's RL time, they might have to adjust time twice a year. But that's better than adjusting the time four times a year.
primerib1 Resident
Rathgrith027 Resident Point 1 ... do you know that there has been HUNDREDS of attempts by the US Congress to do away with DST? None, not a single one of them, ever saw fruition.
How much longer to wait until we have a time that's truly monotonic in SL? Why not just do away with DST? And while at it, use UTC for simple, one-arithmetic-operation conversion to everyone's local timezone?
primerib1 Resident
Rathgrith027 Resident Point 3 is still relevant. At the transition time backwards, there will be TWO points in time that has the exact same SLT.
In 2024, the clock goes back at Nov 3, 2am. So if there's a problem at 1:30am SLT, when does that actually happen? 1:30am while still in DST? Or 1:30am after the clock rolled back to 1am?
How do scripts handle this? By using the llGetTimestamp() function which, surprise surprise,
already
produces monotonic UTC timestamp. [1]Buuuut then the script has to do additional processing trying to detect if SL is in DST or not, then shift the time yadda yadda yadda ... more bytes consumed & more script execution cycle wasted adding to the very real problem of script lag.
primerib1 Resident
Rathgrith027 Resident Additional thoughts about your rebuttal of my Point 1:
Relying on the very vague and faint hope that the political entity where LL is located in will one day, some day, in the future maybe perhaps hopefully will begin to ruminate on planning for the preparation of thinking about doing away with DST ... and then the DST rule still depends on governmental whims ... like "yeah let's remove DST" next year "let's reimplement DST" next year "let's make it permanently DST instead" next year "let's go back to non-DST" next year "let's advance by 30 minutes and this is the last change I swear" next year "let's retard by 30 minutes it was a bad idea"...
Rather than depending on the whims of not-really-bright people in politics, let's just use a standard that is internationally defined, internationally accepted, and internationally maintained: UTC.
Patchouli Woollahra
It also makes handling times in UNIX format more consistent as they are pegged to UTC, no DSTs, since a certain date and time, in seconds since that moment.
Nyx Onyx
I don't know that it matters which timezone we pick, but we certainly don't need DST in SL - it's enough to have one time change per year, in RL, and that's too much too for no good reason. I vote for this Canny more to the meaning of going off DST, not voting for a specific timezone.
SarahKB7 Koskinen
I approve of the idea of using GMT instead of SLT, as GMT is an established and universally recognised time system. And also because GMT is my home timezone! :)
Load More
→