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
primerib1 Resident
At the very, VERY least, STOP using DST.
That would be the first step.
Afterwards, it will be easier to just adopt UTC/GMT as the final iteration of what SLT is pegged to.
Huns Valen
Opposed if we're talking about the default behavior.
Not opposed if we're talking about an individual client-side/per-user thing that doesn't break existing content, or change from one arbitrary time zone to another arbitrary time zone to make people in Europe and Africa happier at the expense of everyone in North and South America, who are in the majority; while providing no benefit to anyone in Asia or Australia either.
Come on. You think someone in Canberra is like, "Barmy mate, who cares what time it is in my own country? I only care about what time it is on the other side of the world, in Greenwich! I wish everything in Australia was in GMT! How silly and embarrassing that it isn't!"
GMT and Pacific time are equally alien to someone in Canberra, or Tokyo, or Yakutsk. All of Australia is not walking around with dual-time watches, hanging two clocks on the wall so they can constantly know what time it is in England. They don't care about GMT any more than Europeans care about Pacific time.
If we're talking about simulator time, specifically what llGetWallClock() returns, that is quite impossible. That would break decades of content that can never be fixed. Forget about it, they will never do that.
Re: UNIX time being on UTC for back-end, yeah, but what programming language are you using where "convert Pacific time (with automatic DST detection) to UTC" isn't a one-liner you get from some open-source library? This is not a real problem. This is not even 1% of what you will spend your time solving in your Linux program.
Now, here's the real deal:
If they want to add a feature to let you set your own time zone in the viewer, and translate stuff in the viewer thusly, and add some kind of dataserver event to get an agent's preferred time zone, I'd support that fully. THAT would actually be BETTER than this proposal, because it would address EVERYONE in EVERY TIME ZONE.
Not just the one that people in Europe and Africa wish SL would use. That would give better coverage for daylight saving time as well, although some places within a TZ don't follow it. A checkbox for "use this time zone's DST" would solve that, just like it does in a car's GPS unit.
Even the people in Europe, who are pretending this isn't about advantaging them specifically, would be better-served. If you're not in GMT, you still have to do math, so this helps you as well.
primerib1 Resident
Huns Valen If someone handles Linux servers day-in and day-out, conversion to and from UTC is kind of second nature. Furthermore, for people in areas that do not practice quaint behaviors of moving the clock back and forth because of outdated tradition, the conversion to/from UTC became automatic.
Auto translating won't work if the event is promoted, like, using a poster texture. There is no way an automated system can reliably "read and edit" an image. Plus all the embedded time in the notecards. I don't think any viewer can reliably detect references about event time, without false positives.
primerib1 Resident
Huns Valen as to llGetWallClock(), name me a purpose where it is not used to determine 'phase of day' or, well, a Clock showing current SLT time.
If those are the purposes of calling llGetWallClock() then there really is no problem.
Huns Valen
primerib1 Resident
You're right, converting between arbitrary time zones and UTC is extremely simple, to the point where it's hardly worth mentioning. Whether you find DST "quaint" is irrelevant because your preference is not the only one that matters, and people running events are going to want to publish them in a time zone that makes sense to them, which is very often not going to be UTC. Telling people they have to publish events in UTC and then, what, put that on posters? Most people who are not within a few time zones of UTC are not going to bother with any of that because it will make no sense to them. Just like Pacific Time makes no sense to Europeans, which is why I advocated for a more universal solution.
Let me know when you have figured out what every last script using llGetWallClock() is doing. I think that might take a long time.
Spidey Linden
Merged in a post:
Add in easier time zone finder in SL
Yevgeny Varthader
Add in different time zone options in a slider form in the SL Clock to allow international users to make better appointments and bookings for SL events, without having to look on Google for time zone differences.
JaneRustle Resident
If this helps me not be an hour late (or early) when the clocks change at different times in US & Europe, it gets my vote!
VenKellie Resident
totally agree as im in eastern Canada, kinda a pain to add 3 hours to SLT in my head
Shai King
VenKellie Resident you do realize SLT is PST right?
VenKellie Resident
Shai King no s sherlock
Shai King
VenKellie Resident that was a legit question lmao. No need to be rude. Some people really dont know that.
VenKellie Resident
Shai King well it came off as if i didnt know. i aint stupid, just do dumb things
Huns Valen
VenKellie Resident So you want to subtract three hours instead?
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.
Load More
→