|
|
|
We're approaching the transition day when PDT goes back to PST again... and this means, once again, that SL's in-world clock is going to be out of sync for 80% of its non-US population for a few weeks, until the rest of the world switches back from daylight savings too.
It hardly makes any sense to establish the "in-world" time as PST/PDT with the international audience of SL — but even the old argument that "the grid is located in San Francisco" does not apply any longer. Even LL's own grid spans several timezones, and it will span more and more as LL adds more data centres on different countries (like the UK and Australia). A suggestion for a transition phase would actually be quite simple: a checkbox to display on the SL client either PST/PDT or UTC (or both, side by side). Depending on the checkbox, in-world events would be listed as either PST/PDT or UTC as well. Universal Time makes sense.
The client can actually show UTC. It could even show the user's systems local time. How that coordinates with event scheduling presents a problem, but not an unsolvable problem at the client level. Events could be displayed in a user's local time instead of SLT - or both. The client can detect a user's local time from the operating system itself. The hooks for the operating systems supported are pretty well documented for something like this. Coordinating server time on the website to local time by the users is actually commonplace in many content management systems, and is not a difficult addition in PHP. The biggest problem for non-US SLers, like myself, is that I now exactly what my timezon is relative to GMT (UTC) but, even though I try to remember, I struggle to do the conversion in moments when someone is discussing for example meeting up sometime. Even now the conversion to CAT from PST/PDT has eluded. Is it PST or PDT now? Or have the US congress decided to readjust again?
And where I am from, we do not even use daylight savings, which confuses matters even more... Another idea as opposed to changing it suddenly, is allow users to put in their own timezone and display the timezone difference next to SLT. You can then also allow the client to display the time for an event scheduled in SLT in the users local time. I see no reason to wait until November to correct this confusion. The next time the grid is down for maintenance, bring it back up in GMT.
I concur with Burton - since SL time would be moving forward a few hours, you wouldn't even need the grid to be offline for very long. But I wonder if the viewer's displayed clock timezone is hard coded locally by default, or if the login server supplies a timezone for it to use - does anybody know?
SL made this mistake. then SLEX made it again. everyone uses their local standards as world standards. blame local pride/arrogance, short sightedness, or both. in general this for example also affects languages. the only reason SL is in english, is because it happens to be the native language where LL's headquarters is located. also note how they use AM and PM at all, even though they suck. makes me wonder, however, why building and scripting in SL don't use imperial units. nice little editboxes to enter the feet, inches, etc separately.
if this has not been done yet, code should be made to set the timezone from a central point, so LL can change the timezone and it's name instantly at any time. even if LL keeps the time as it is now, that exact system would be used to change between PDT and PST
Pretty much every web service operates on GMT. Second Life shouldn't be any different. Gets my vote!
Lex has once again read my mind.
Glad to see this is finaly getting some attention.
This would be indeed a positive signal for international SL community. My opinion is that there shoudn't be a transition period because it only confuses people when some of the times are in PST and some in UTC. You know, there wasn't a transition period when Swedes changed their left-side traffic to right-side...
 Let us resolve to have the change made by the time the wall clock changes (in all its different timezones) this Spring.
While we are at it let's throw away this antiquated am/pm thing. We have 24 hours in a day and am/pm just complicates it all again. Get with it. I will stop short of recommending that we change the time stamp to ccyymmddhhmmss. @Gregory, issues of representation of time can be changed at the client level, so that'd be a separate issue from how the grid (and sims) reckons the "SL Time zone".
I've never actually checked – I take it the SL client always uses the traditional USA time/date representation rather than following the user's OS/desktop preference? E.g. as set by Windows' "Regional and Language Options". That sounds like a relatively straightforward client change, if so – perhaps worth its own JIRA issue if anyone is interested. ( Don't forget to include the ISO 8601-mandated "T" between your date and time! I would be interested in hearing how a change to the SL Time zone might break existing in-world content of any significant sort. What are the downsides to a change from PST/PDT to GMT (or UTC), other than inertia and tradition? I would suggest that it would be a good thing to have the client show local time or SL time, as selected by the user... But rather than the people asking what are the downsides, as any fairly major change like that one has quite a bit of potential to shake out all kinds of interesting bugs (ask the Zune 30G users about this one!)... What are the actual upsides to the functioning of SL of making this change? We're pretty lucky, actually, that Linden Labs didn't make SL time follow the 4 hour day/night cycle of in-world, complete with a SL calendar that would have SL Years...
The time base point for the world is a pretty arbitrary thing - much like the choice made to drive on one side of the road or the other. It works fine, as long as it's followed by everyone in a particular region. This is why Linden Labs named it Second Life time, to indicate that it's the time used within Second Life, so as to coordinate things. Personally, as the US has 4 time zones on the main continent, I use a small HUD I made that shows up to 6 different zones, labeled (nice what you can do with 6 XZZYZ-10 prims and a black background). I do intend to start selling it at some point, having the script check the difference between UTC and SL time to decide whether or not to use daylight savings time... However this is still going to leave people out of sync, because so many different areas use oddball DST start/stop times, set by their own countries - and then there's the oddities of half- and quarter-hour time zones, and the mess that is Australia with both horizontal and vertical timezones... Anyone thinking time zones are simple hasn't looked at the 1.37MB compressed file of time zone data for Fedora 10. Talk about a mess! Well you can add my support behind a move to UTC as Second Life time and also the implementation of ISO 8601 for ALL date and time stamping. Again, this is an application used INTERNATIONALLY. Therefore, an international standard should be implemented. Period. No AM/PM, no mmddyy, no nonesense... please!
i completely agree with Alger Voight: UTC and ISO-8601 are the way to be international. i completely agree with TaraLi Jie for equating complexity with the amount of information needed to represent something. seconded!
i think using local time anywhere is not desirable because it further divides people up. we already have language barriers to deal with. i like SL as a global community where people can interact with each other. as we already don't officially use local time anywhere in SL, moving to using it would be a change. Of all the things that REALLY need fixing in SL...the time is at the very bottom of the list...Does everyone really need more than one clock on their desktop to tell them what the damn time is? Seems to me alot of you are spending way more time in SL than you are in RL...Remember what the outside looks like? Or maybe even the sun?
Well, @Tal Chernov, the issue is really about improving coordination between persons and events in wildly differing timezones. The 'normal' priority of the issue reflects the fact that no one thinks this is an earth-shaking issue, but perhaps a potentially useful one to discuss. That's what the public issue tracker here is all about, aside from reporting egregious bugs.
As opposed to, say, people with lots of time on their hands trolling around leaving vapid sermons. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
Redefine SL system time as UTC/GMT instead of PST-PDT California time
One thing though: a lot of people have grown used to using SLT, confusing or not. I don't think it would be a good idea to switch suddenly, especially not without ample warning. I think a transition period would be nice, in which SLT and an international time were both displayed in the client. Allow the user the option of changing the SLT display to their local timezone. Having SLT visible would be nice because events are currently scheduled in SLT, and having the ability to display your own timezone will ease people into thinking in GMT or UTC.