My website has regularly user-scheduled events. Right now we are using our timezone EDT (or EST) as the base timezone for all events on the site. I feel like this is either 1) wrong, or 2) very confusing. Currently, we have users all over the US and Europe.
Is the proper method to localize times based on the clients' time zone? use UTC/GMT?
Thanks
Honestly, this is one issue that is frequently seen when having a website used by multiple time-zones. There is a long-list of ways to overcome the battle. To summarize badp, there's a lot of contributing factors as-to how different timezones are processed.
Most websites opt into one of two different solutions to address this problem:
1) Store anything involving a date as UTC in the database... and allow a user-defined setting for users on your website to pick what timezone they're in... or do some geo-ip-lookup magic to find out where in the world they are and find the appropriate time-zone... and then every time you display the date... make sure to call whatever function needed for localization. Nearly every programming language has some method for displaying dates using a specified timezone. You would also have to do this in reverse for users inserting dates. (take local time & convert back to UTC for DB storage) This is probably the most common approach. This would also save you a lot of time from trying to "re-inventing the wheel". As far as anonymous visitors go... you can either A) stick with EST/EDT (using built-in function calls for displaying as appropriate) or B) revert to the Geo-IP-Lookup thing & pick a timezone based on an educated guess. It's also a good idea to always specify the time-zone you're displaying the date/time in. i.e. never say "12:00" ... make sure it says "12:00 EDT"
or 2) Follow stackexchange's model (and many others) of displaying the difference between now & when the post was created. i.e. instead of "posted on x date" ... you would do "x hours ago" or "x days x hours ago" etc... or for future dates... "in 6 days 14 hours..." This is quickly becoming more common for many situations... but isn't as ideal for calendar-type schedules.
Of course... you can still adopt some kind of hybrid of the two... and you may need to even go one step further and store dates as utc... but also store a specific time-zone for an event. Ultimately, the decision is yours.
Here's the problem: the EU and the US do not turn DST on and off at the same time; this March, there was a three weeks' difference between these events.
Here's what happens during this period. Let's say you have an event every day at the same time and, since you are based in the US, you are going to adjust times using the US DST.
Day (2001) United States Europe United Kingdom Global Time delta
March 5th EST 1500 CET 2100 GMT 2000 GMT 2000 +23h
March 6th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
March 7th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
..............................................................................
March 26th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
March 27th EDT 1500 CEST 2100 BST 2000 GMT 1900 +24h
Let's analyze all possibilities:
If you display the time in a global timezone and call it UTC, which feels like the right thing to do, you're going to confuse your American customers, who are going to see different UTC times (yesterday 8pm, today 7pm) for the same wall clock time (yesterday 3pm, today 3pm again), and then your EU based customers, who don't see the posted time clock change and yet must change their wall clock event time.
If you display the time in a global timezone and call it GMT, in addition to confusing US customers you'll also confuse UK customers who switch from GMT to BST. It is counterintuitive to understand that EDT 1500 and EST 1400 are the same moment in time; now translate that into BST/GMT (with the additional problem that you're not going to be showing BST times in any part of the site).
If you display the timezone in an EU timezone (I used CET/CEST to avoid GMT/UTC confusion), that's obviously going to be super confusing to your US customers, who see the event time switch back and forth twice and yet experience no wall clock time change themselves. While your US customers may be prepared to the first switch (after all they have to change their wall clocks on the same day), they'll be surprised by the latter.
If you display the timezone in the US timezone (like EST/EDT), you're going to have the exact situation explained above, but mirrored!
This seems like an hopeless situation! Here's how I came to address it after four years of going through this rigmarole (twice a year, obviously): "make up a timezone."
I am in exactly the situation pictured above, so I made up "NYT" (New York Timezone) so that I could write "1500 NYT" to mean "3pm in whatever timezone it is New York happens to be using."
This has the advantage that, so long as the user knows that the DST waltzer is happening, he has a very simple way of converting back and forth to their own timezone: google "time in new york" to see what time it is in NY, then work it out from there. You can even get fancy and use geolocation-based services such as time.is/15:00_in_New_York.
Note that, while you could use timezone abbreviation names in time.is, I urge you not to, for they are pretty confused about it all themselves: EST has the same time as EDT‽
You can notify users about DST with some short blurb, linking to an appropriate time conversion webservice to help people out. Ideally all timestamps should have an option to be converted into local time.
When all's said and done, you should realize I've been ignoring the elephant in the room all time long, and that's the "countdown" solution you have already implemented. There's nothing confusing about "in 1 day 2 hours 45 minutes 47 seconds" (and if you believe you don't need that much precision you might want to think again).
Sure, in my experience I never had the luxury of anything that wasn't static text, so I had to handle the incredible mess pictured above (and that's only the beginning of it! How about the southern emisphere, that does DST backwards?), but for your use case it sounds like the solution with the least potential for confusion. You might get two threads a year asking about "in 23 hours" and "in 25 hours" events while it normally counts down from "in 24 hours", but that's it.
