What is OpenSim standard time?

(Image by Leo Reynolds, via Flickr.)

Here at Hypergrid Business, we’re in the process of launching a virtual events directory (now that the vendor directory is up and working).

And the question comes up — what times do we list events under? The Second Life events directory shows everything as SLT time — which is the U.S. Pacific times zone, where parent company Linden Lab is based.

Since the Second Life viewer clearly shows the time in SLT, it’s easy for users to figure out when to get to a particular event.

With OpenSim, there are no such considerations — there is no single company setting a common time zone for the entire service.

There are several alternatives.

Eastern time: Since Hypergrid Business is based in Massachusetts, we can dictate U.S. eastern time as the standard for all our listings. This will confuse readers who are used to SLT immensely, and add an element of fun and whimsy to the discovery of virtual events.

Pacific time: Silicon Valley is the new center of the universe. Everyone knows this. Might as well bow to the inevitable and go with PST.

Local time: Event organizers have to be located somewhere. They can pick a time zone that is convenient for them. For example, a German grid can list their events under standard German time, and a French grid under their own time zones. This will make it easy for local users to attend the events — but will create headaches for folks in other areas trying to figure out the time zone conversions.

All time zones: We can list several time zones for each event — Pacific, Eastern, GMT, Hong Kong. Let readers pick and choose which time zone suits them.

GMT/UTC: Greenwich Mean Time — or Coordinated Universal Time —  is already the global standard, even if many people in the U.S. have never heard of it (blame our educational system). Using GMT will make it more difficult for some people to get to events, including those of us who are easily confused. This is the target demographic for many marketers, however, as well as of any organization offering educational programing.

Your time: Anyone who registers on our website gets to pick their preferred time zone, and all times are recalculated appropriately. The programming challenge of how to do this is beyond me, but there are probably WordPress plugins out there already that can handle it. Alternatively, the displayed time can be based on the user’s browser settings.

What do people think? Any advice?

Related Posts


Maria Korolov

Maria Korolov is editor and publisher of Hypergrid Business. She has been a journalist for more than twenty years and has worked for the Chicago Tribune, Reuters, and Computerworld and has reported from over a dozen countries, including Russia and China. Follow me on Twitter @MariaKorolov.

9 Responses

  1. I think UTC is best: it's an international standard and it does not vary with season. Some people are unfamiliar with it, but heck, if they're using open sim, they really should be able to figure out something like time zones. It's already used in any *nix or php-based time selection menu, as well as being the standard for amateur and short-wave radio.

  2. Ron Overdrive says:

    We discussed this a long time ago in an ImpDev meeting held by the Imprudence Team. Due to UTC being -THE- international standard for all computer related and communications technologies we felt UTC is the way to go for the Hypergrid so UTC clock support was added to Imprudence a long time ago in a 1.3 Beta. UTC clock is an available option in the General Preferences Tab on Imprudence 1.3 and up.

  3. fons.tuinstra@hypergridbusiness.com' FonsTuinstra says:

    Every advantage has its disadvantage, to quote a famous Dutch soccer player.
    Over the weekend it was very hard to figure out when some virtual events were taking place, since in many parts of the world countries shifted from summer to winter time.

    I would vote for GMT: it is a solid standard, and has not winter or summer time. If you go for an international system it seems the only valid time. Even though a lot of people, including us Europeans, have to get used to it.

  4. Pathfinder says:

    Definitely GMT/UTC. It’s an international standard.

    Or we could go with Swatch Time. If we’re feeling particularly obtuse. 😛

  5. Pathfinder says:

    As for tools to help folks navigate the choppy waters of timezone conversions, I personally find this site invaluable. http://timeanddate.com/

  6. coyle@knifejaw.com' coyled says:

    While I’m a big proponent of UTC for these sorts of things (and a bit of a time nerd), I haven’t been happy enough with any of the web-based conversion tools I’ve found to recommend them. So over lunch today I created http://utc.is . Right now it only shows the current time in UTC, but I’ll add some conversion tools to hopefully make things easier for people to convert back and forth from a preferred time zone. Ooh, and I’ll need an API of some sort so I can pull this info into an in-world HUD. Fun stuff.

  7. owen@owenkelly.net' owen says:

    FWIW I also agree with UTC.

    Its a solid base, and anyone can/should know where they stand in relation to it. I live and work at UTC+2, for example. So I can figure out in an instant what time in Helsinki a meeting at 10:30 UTC is. It takes me 2 jumps, and several double checks, before I figure out when I should get ready to meet someone at 10:30 SL time.

    But that could just be me 🙂

  8. ideiaboa@gmail.com' Ideia Boa says:

    I also agree with GMT/UTC..

  9. Tre Critelli says:

    A timely post as I have been mulling over the same issue after putting the Hypergrid Adventurers Club meetings on my calendar….

    As has been noted, there is no need to reinvent the wheel as far as the appropriate time reference to be used across the Hypergrid. We need to use the world standard, known as “coordinated universal time” or UTC (formerly GMT), which is what we use in all international radio communications. In the ham radio community we have countless applications already available to assist with conversion.

    However, proper UTC/GMT time needs to be in twenty-four hour notation: 1pm = 13:00. This avoids confusion and will allow for a uniform time coordination across all grids. I see this as being the real programming issue.