Tag Info

I don't know where I saw it, but the best timezone picker I ever saw allowed you to pick a map that had shaded bands for timezones allowing you to pick the band. It was the easiest I've ever seen and the most intuitive. Ubuntu for example:

getTimezoneOffset() The simplest solution should be to call getTimezoneOffset() on a every login or page load, and not burden the user. I don’t know why it isn’t working for you; I thought getTimezoneOffset() accurately accounts for geographic location and local DST practice. Maybe you should investigate this some more to understand when, why, and how much ...

In the few times I've done this, we've always followed the format: Time Zone Name (offset) In very brief user testing, we found that users looked primarily for their time zone name and didn't always know the offset from GMT (or UTC). So we have that field first. I don't believe our users knew (or cared) about whether the offset should be from GMT or UTC. ...

One other alternative I could see is integration with location-data and something like the Google-maps api that can handle typed-in locations quite reasonably. I've not yet seen this integrated in timezone pickers, but it is used in weather apps. (I am not sure it is the best alternative, but I wanted to make it available anyway.)

The list you refer to contains tons of duplicates. If you look at the list of time zones in Wikipedia you'll find 40 different time zones. Since you were asking for a 80% solution it's safe to cut the list by 12 (the ones with a 30 or 45 minutes offset. That leaves you with "only" 28 options. The list you've shown contains many duplicates. Still you're left ...

Is there one timezone where the event is taking place? Can you do something like... download bmml source – Wireframes created with Balsamiq Mockups If you're listing this many, it may be better to spell out "Eastern" and "Central" as otherwise, it gets kind of acronym heavy. P.S. If you want to get really into it, you'd use EDST, since not ...

The question is why bother ? Why dont you use geolocation or ip tracking to determine where the person is located (in what time zone) and then just display the time zone for that area Should the Day & Date be on a separate line from the times displayed ? - Yes ,just for easier readability, I would recommend posting the date first and then the time since ...

Assuming the DST flip is at 3am based on your example (isn't from 12a - 1a?), you can't know which 3a someone means if they log that time. They could come in at the 2nd 3am (after the switch) or arrive at the first (before the switch). When that time overlaps the DST changeover, you need to prompt them with something like: some sort of flag to indicate ...

Use a simple drop down, but pre-populate it with your best estimate for their zone. You can get the zone from the ip, or use javascript. Users will rarely have to change the selection. When it comes the the actual formatting of the list, i would recomend that you look at windows (or mac). They use conventions people understand. You may also allow users ...

The time zones include the time offset and Daylight Saving settings. Your application needs to know the time zone to function properly. Since there are multiple time zone formats your users might know ( UNIX, Windows... ) it is always better to set the time zone based on the user location. Ask them for their country ( the majority are in one time zone ), ...

If this problem is being solved for a website, and its about displaying some event time in local time for every user, then you may like this solution: we never ask our users to enter thier timezone. Instead we store time in UTC and convert it to local time automatically when it come to displaying data. This conversion has to be done on client side since ...

I did not implement anything on this, but I have an idea on how this could be done. One way to do this is to use the user's system time using javascript and figure out the offset. new Date() would give out something like this Wed Aug 17 2011 13:00:00 GMT+0530 (IST) If you don't want to go with the above or have a backup, you could get the country ...

A few thoughts: You should be storing your dates in UTC on the server no matter what. That way you get the timezone shift for free using javascript to do the conversion on the user's system. The second thing is that it depends on how you calculate the due date. Are you using a duration or a fixed date. Let's say you are in Australia and your user is in ...

You should leave it to the "system" to keep track of the timezones (and daylight saving time for that matter). Your app should just check if (System.TodayDate = Task.DueDate) then Task.Highlight('Due today!'). I don't think it will be a problem for the user, because the day he/she travels "with the sun", the day will in fact be several hours longer. ...

Most people will be looking for the time zone names, or cities, and not specifically for the number, so that could be a reason to list the offsets last. On the other hand, offset first also makes sense to me, for this is the variable that determines the list ordering. It makes the ordering explicit, and if the amount of space for you list is wide enough ...

Speaking as someone who does this on a regular basis (Israel, UTC +02:00), I can tell you how it works for me. I think the Windows approach is great, because only the zones used as standards really have names, and the others are denoted by different cities. There's a huge number of cities, and they share a relatively small number of timezones (about 30 - ...