• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Dealing with time zones in web application

C

chockomonkey

[H]F Junkie
2FA
Joined
Oct 11, 2003
Messages
8,458
I'm trying to get my application to display times correctly to users depending on their choice of timezone, like how this forum works.

Using pytz (a python timezone module) seems wildly popular as a way to create and assign timezone objects for easy conversion from UTC, which is how I store times in my db.

The trouble is, there's about 400+ timezones in the pytz.common_timezones list, and while that's great for accuracy, it's quite a bit too much to ask users to sift through.

I'm asking this here, because this site has a much more streamlined approach to time zones. Here's the choices that [H] gives its users:

t1ete2w.png


We have users here all over the world, so my question to you is: how do these narrowed-down timezones work for you? Have they been accurate enough? Have you found that there is no right choice for your locale?

And perhaps, if you've tackled this problem yourself, how'd you go about it?
 
Does pytz use tzdata?

While tzdata might not be small, I think it's pretty easy for a regular user to figure out. Timezone are grouped together so it's quite easy to sift through.
 
krogen said:
Does pytz use tzdata?

While tzdata might not be small, I think it's pretty easy for a regular user to figure out. Timezone are grouped together so it's quite easy to sift through.
Click to expand...

It uses the Olson Database, which from my quick search is called tzdata, so I'm going to say yes.

And it does have country groups available, but it's just not what I was expecting I guess. From my research, Eastern, Pacific, Mountain, etc are depreciated? ...and so here's the list of timezones for the US:

America/New_York
America/Detroit
America/Kentucky/Louisville
America/Kentucky/Monticello
America/Indiana/Indianapolis
America/Indiana/Vincennes
America/Indiana/Winamac
America/Indiana/Marengo
America/Indiana/Petersburg
America/Indiana/Vevay
America/Chicago
America/Indiana/Tell_City
America/Indiana/Knox
America/Menominee
America/North_Dakota/Center
America/North_Dakota/New_Salem
America/North_Dakota/Beulah
America/Denver
America/Boise
America/Phoenix
America/Los_Angeles
America/Metlakatla
America/Anchorage
America/Juneau
America/Sitka
America/Yakutat
America/Nome
America/Adak
Pacific/Honolulu

I had no idea we had so many :eek:
 
chockomonkey said:
It uses the Olson Database, which from my quick search is called tzdata, so I'm going to say yes.

And it does have country groups available, but it's just not what I was expecting I guess. From my research, Eastern, Pacific, Mountain, etc are depreciated? ...and so here's the list of timezones for the US:

America/New_York
America/Detroit
America/Kentucky/Louisville
America/Kentucky/Monticello
America/Indiana/Indianapolis
America/Indiana/Vincennes
America/Indiana/Winamac
America/Indiana/Marengo
America/Indiana/Petersburg
America/Indiana/Vevay
America/Chicago
America/Indiana/Tell_City
America/Indiana/Knox
America/Menominee
America/North_Dakota/Center
America/North_Dakota/New_Salem
America/North_Dakota/Beulah
America/Denver
America/Boise
America/Phoenix
America/Los_Angeles
America/Metlakatla
America/Anchorage
America/Juneau
America/Sitka
America/Yakutat
America/Nome
America/Adak
Pacific/Honolulu

I had no idea we had so many :eek:
Click to expand...

You can blame certain local governments for that. The lower 48 haven't had a simple 4 time zone layout in a long time.

With these complications in mind from a UI perspective it is easier and more accurate to ask the user "What city or political entity from this list uses the same time you do all year?", hence this list.
 
Last edited:
devman said:
You can blame certain local governments for that. The lower 48 haven't had a simple 4 time zone layout in a long time.

With these complications in mind from a UI perspective it is easier and more accurate to ask the user "What city or political entity from this list uses the same time you do all year?", hence this list.
Click to expand...

I'll have to do just that, then. I guess part of my setback was simply that I expected this to be simple, as it seemed so simple in applications we use at work, on forums such as this, etc. So I just wasn't mentally prepared for a much larger and daunting task.

But indeed you're right--I'll have to have probably multiple drop-downs. One for Country to narrow down the second drop down to something more manageable, since it is apparently necessary for accuracy sake, to have all these choices presented.

I am curious, for members of this forum from Arizona, how the timezone choices here work for you.
 
JavaScript has a function prototype on the Date object that can return the client's time zone offset, getTimezoneOffset, that could be used to pre-select the most likely correct time zone from a select field.
 
It's always better to save it in UTC and then convert it for each user personally depending on its timezone settings.
 
wonderfield said:
JavaScript has a function prototype on the Date object that can return the client's time zone offset, getTimezoneOffset, that could be used to pre-select the most likely correct time zone from a select field.
Click to expand...

I did look into this, but from what I read it can be wrong sometimes. Better to be right all the time for a little more work than wrong and annoy users and have it be out of my ability to fix.

zepad said:
It's always better to save it in UTC and then convert it for each user personally depending on its timezone settings.
Click to expand...

This is what I ended up doing. All times are stored in UTC, and I apply a filter which takes the users stored timezone info, if available, and converts it to their local time.

The only problem I still have with this is the time it took to implement the list, and possibly the confusion a user might have when they also look at the list.

Code: 
us_timezone_names = (
	'(UTC -5:00) New_York',
	'(UTC -5:00) Detroit',
	'(UTC -5:00) Kentucky/Louisville',
	'(UTC -5:00) Kentucky/Monticello',
	'(UTC -5:00) Indiana/Indianapolis',
	'(UTC -5:00) Indiana/Vincennes',
	'(UTC -5:00) Indiana/Winamac',
	'(UTC -5:00) Indiana/Marengo',
	'(UTC -5:00) Indiana/Petersburg',
	'(UTC -5:00) Indiana/Vevay',
	'(UTC -6:00) Chicago',
	'(UTC -6:00) Indiana/Tell_City',
	'(UTC -6:00) Indiana/Knox',
	'(UTC -6:00) Menominee',
	'(UTC -6:00) North_Dakota/Center',
	'(UTC -6:00) North_Dakota/New_Salem',
	'(UTC -6:00) North_Dakota/Beulah',
	'(UTC -7:00) Denver',
	'(UTC -7:00) Boise',
	'(UTC -7:00) Phoenix',
	'(UTC -8:00) Los_Angeles',
	'(UTC -8:00) Metlakatla',
	'(UTC -9:00) Anchorage',
	'(UTC -9:00) Juneau',
	'(UTC -9:00) Sitka',
	'(UTC -9:00) Yakutat',
	'(UTC -9:00) Nome',
	'(UTC -10:00) Adak',
	'(UTC -10:00) Honolulu'
)

To keep it more simple, i looked at our client lists. We mainly deal with US and CA so i just included those and will add support for other countries if necessary.

It's still not as pretty as what [H] has, but it should be more comprehensive where necessary.
 
chockomonkey said:
I did look into this, but from what I read it can be wrong sometimes. Better to be right all the time for a little more work than wrong and annoy users and have it be out of my ability to fix.
Click to expand...

I think he was saying pre-select the choice on the dropdown based on a likely correct answer, but allow them to change it still.
 
Sgraffite said:
I think he was saying pre-select the choice on the dropdown based on a likely correct answer, but allow them to change it still.
Click to expand...

oh... that actually makes the most sense. Thanks for the clarification, will add that to the to-do list =D
 
Just FYI

Code: 
'(UTC -5:00) New_York'

The 'America/New_York' changes its UTC offset between -5 and -4 depending on time of year. So you may not want to not hardcode the offset in the list.

Many other timezone selections work like this as well.

Remember in this format the DST info is already included in the zone selection. This is the fundemental difference between selecting a Time zone and selecting a UTC offset ([H] forums does the latter as you noted in your OP).
 
Internationalisation is a can of worms (more like a minefield!).

As the guy above mentioned, time-zone offsets [may] vary depending on the time of year. There's also sub hour zones, UTC+6 hours wasn't good enough for Kathmandu, they wanted 5 hours and 45 minutes - arseholes! :rolleyes:

But the above aren't the biggest issues. The biggest danger is dates being interpreted differently. Take 06/12/14, in the UK read 6th December 2014, but in the US it would read as June 12th 2012, that's just the tip of the iceberg!

Unless you have loads of time on your hands (or like pain), go with a stranded library. Then you only need to get their country code and then find the bugs in your existing code.



I didn't even touch currencies, exchange rates or official languages to accommodate each country.:eek:



As you can probably tell, I've come across this before. The most elegant way (in .net) was to create extension methods to do the conversion for datetime & decimal to take the user context. So you end up with dateModified.Date(User), which kept the code much cleaner.
 
You must log in or register to reply here.
Back
Top