I want to schedule an online multiplayer game tournament, one per unique country, with a convenient start time for as many registered players as possible.
A global start time based on UTC is inconvenient for a number of countries. For instance, 17:00 UTC might be fine for those in the US but not in Australia.
Thus, I'd like to let each country have its own start time, say 17:00, but based somehow on the country's local time. The issue is that many countries have multiple time zones.
Would you recommend I take the average of the time zones per country? For instance, in the US, the start time would be 17:00 for those in the middle of the country, and +/- 2 hours for those on each coast.
I could further try to bucket users by timezone and have separate tournaments per time zone instead of country but that adds more complication to the design and prolongs the tournament to multiple mini-tournaments. That is, if you win your tournament in timezone A for your country, you still need to defeat the winners of the timezones B, C, ... for your country to be declared the country/national winner.
I'm not concerned about users understanding all of this (of course). I'll just show them a notification when it's time to play. I'm focused more on picking a convenient time to keep engagement up.
Has anybody dealt with this issue previously? How did you "solve" it?
Thanks for your thoughts.
Is there an "average" time zone per country? No. Many countries have multiple time zones. Sometimes a given country's time zones are not even near each other, due to the time zone applying to an island or overseas territory.
But could you create one for the purposes of your game? Yes. Of course, it won't necessarily reflect reality of the world. Some users would be behind the time in that zone, and some users would be ahead.
You might consider just assigning a separate start/end time for different groups of tournaments. For example, you could say that the US tournament starts at 8AM Central Time. It wouldn't matter whether or not users in other US time zones had the same local time or not - they would just start earlier or later in their local time accordingly.
China has 1 timezone. So it's probably just US, Canada, Russia and Australia that seriously use multiple timezones - might be worth just hardcoding those (for example to their capitals in most cases).
But there are few countries that less seriously use multiple timezones: Gran Canaria is 1 hour behind the rest of Spain. Guadeloupe is 6 hours or so behind the rest of France (= GMT+1). You 'll want to ignore that for France, because the average (= GMT-2) isn't what you want.
Related
I hate timezones, but this time I can't get by without them. I'm building an app with flutter that needs to preselect the user's timezone but still allow to change it. What timezones should I display?
After doing some research and looking at examples, I noticed 2 patterns
display timezones as city names. Ex "America/Denver"
display timezones as timezones. Ex "Mountain Standart Time"
I decided to go with the city name example because it was the easiest to code. This pattern is used in the "timezone" flutter package, iOS and Android devices, and returned when I query the user's timezone with the "flutter_native_timezone" package. This implementation, however, generated a lot of negative feedback from test users. Most people wanted to see Mountain Standard Time on the list. They also said if I'm using city names for timezones, I should pick the largest city if they share the same timezone. For example, America/Boise and America/Denver should not be displayed together because they're under Mountain Time and the largest should be included.
Can someone explain how I can solve this mess? Doing this manually is possible for 1 country, but doing this for all countries in the world is very tedious and error-prone. I would like to go with the timezone pattern, but this would require some sort of timezone resolution function that can take "America/Denver" and convert it to "Mountain Standart Time" and vice-versa.
I recommend using canonical TZ database names for timezones.
Have you checked timezone package?
This package provides the IANA time zone database and time zone aware DateTime class, TZDateTime.
They offer three different variants of the IANA database:
default: doesn't contain deprecated and historical zones with some
exceptions like "US/Eastern" and "Etc/UTC"; this is about 75% the
size of the all database.
all: contains all data from the IANA time zone database.
10y:default database truncated to contain historical data from 5
years ago until 5 years in the future; this database is about 25% the
size of the default database.
I'm working on a website interface and I see a drop down that says "Change your timezone". When I click on that drop down, I see a list like this:
CST - America/Costa Rica (GMT -06:00)
CST - America/El Salvador (GMT -06:00)
CST - America/Guatamala (GMT -06:00)
etc...
EDT - America/New York (GMT -04:00)
EDT - America/Nipigon (GMT -04:00)
EDT - America/Toronto (GMT -04:00)
etc...
I vaguely recall working with some PHP libraries and Javascript date libraries that also require you to specify location like America/Toronto and America/New York in addition to specifying the timezone (eg. GMT offset or UTC offset).
My question is why are locations like America/Toronto or America/New York required when working with timezones? Will there ever be multiple political jurisdictions in the same timezone that show different times?
This is the naming scheme of the tzdb. Their explanation:
Each main entry in the database represents a timezone for a set of civil-time clocks that have all agreed since 1970. Timezones are typically identified by continent or ocean and then by the name of the largest city within the region containing the clocks. For example, America/New_York represents most of the US eastern time zone; America/Phoenix represents most of Arizona, which uses mountain time without daylight saving time (DST); America/Detroit represents most of Michigan, which uses eastern time but with different DST rules in 1975; and other entries represent smaller regions like Starke County, Indiana, which switched from central to eastern time in 1991 and switched back in 2006.
Wikipedia has some discussion on the correspondence with national borders:
Country names are not used in this scheme, primarily because they would not be robust, owing to frequent political and boundary changes. The names of large cities tend to be more permanent. However, the database maintainers attempt to include at least one zone for every ISO 3166-1 alpha-2 country code, and a number of user interfaces to the database take advantage of this. Additionally there is a desire to keep locations geographically compact so that any future time zone changes do not split locations into different time zones.
There have been some exceptions: the former countries of North Yemen and South Yemen were both covered by Asia/Aden, and East and West Germany were both covered by Europe/Berlin.
They can certainly cross sub-national boundaries. For instance the US states of Utah, New Mexico, Wyoming, Montana and Colorado (and parts of some others) are covered by America/Denver.
At least one thing is that some locations have daylight saving which changes UTC offset depending on time of year.
Properly time zone are regional zones with same time rules. If you want to go to past dates, you will find that New York and Toronto were using different times. So it it correct that time zone is a location string. If you remember when you installed a new computer, it ask the time zone (continent/city) and not a time offset.
Then you have Eastern (standard) time (EST). This is just an offset compared to GMT/UTC. Some US states may change the time (from one to the other, e.g. in boundary zones). Some states/countries may choose not to use EDT (daylight). But you keep the zone. For this reason it is better to use the notation: "time zone": geographic and possibly fix, "time offset" the difference of time compared to GMT at that time. (and this may changes because of daylight times, but also because political reasons). Usually we use "time offsets" for larger geographic entities, because it is easier to compare times (now but not for historical or future times).
But so. Time offset are well defined (not really: same letters may be used for different times, usually in different continents). Time zone requires a database which it should be updated regularly: rules changes.
I'm testing some API calls and was delighted to see that the seven-day forecast was including the current day. Around mid-day my time, the seven-day forecast changed and started returning tomorrow as the first day instead.
https://developer.here.com/documentation/weather/topics/example-seven-day-weather-forecast.html
My theory is that the servers are in California (or similar timezone). I'm in Stockholm. It was probably still "yesterday" in the server's timezone when I started playing with the APIs.
Any suggestions on how to fix this? Ideally, I'd like to see an additional parameter allowing me to specify my timezone, or (even better) automatic timezone detection of the requester.
The requester's timezone is not used in the retrieval of the weather data. The reference time(zone) is the local time of the location of which weather data is requested. For the seven days weather forecast, the next day is chosen as the start day if the local time is after 15:00.
Using forecast_hourly as product parameter will give you hourly weather data starting from the current local day and not the next day.
After allowing the user to select their timezone many applications ask if the DST adjustment should be made. Given resources like the tz database which contain past and present information on DST observances for each timezone, why do applications ask?
They shouldn't. Usually those that do are not using the tz database and have made invalid assumptions about how time zones work.
It is usually paired with a time zone selection dropdown that only lists numeric offsets, like this:
One should instead consider asking for time zone like this:
By asking for countries first, one can reduce the choice of time zones from the tz database to just a handful for the country. And since many countries only have a single time zone, sometimes the user will just need to select their country.
BTW - Both of the above graphics are from the Pluralsight course, Date and Time Fundamentals, of which I am the author. I cover this issue, and many other similar common mistakes.
You can also read more in the timezone tag wiki, in the section titled "TimeZone != Offset".
There is one common exception to this rule - Microsoft Windows. If the chosen time zone has DST, then Microsoft allows a user the option to disable it:
This is sometimes needed because there are places in the world that are not represented fully by the options Windows presents. Microsoft doesn't use the TZ database for this, but has their own time zones that they maintain.
For example, if you live in Atikokan, Ontario, Canda, the only valid selection in Windows is Eastern Time with DST disabled. Compare that with the TZ database, which has defined a zone specifically as "America/Atikokan".
This can create a problem for .NET developers, as TimeZoneInfo.Local.Id will return "Eastern Standard Time" regardless of whether the DST flag is turned on or off in the control panel. However, if it's disabled, then all of the adjustment rules will have been stripped away. In other words, TimeZoneInfo.Local != TimeZoneInfo.FindBySystemId(TimeZoneInfo.Local.Id). If the application just stores the ID, then it has no way to retrieve the time zone for somewhere like Atikokan.
I'm developing an international software that act as a simple project management software and I'm facing a problem. This problem is about date/hour and time zone.
When a message is sent from one time zone to another time zone I can store the UTC (GMT) time in my database and then have it displayed differently according to the user's time zone. But this can't be done when I only work with date.
If I say a task is due to the 21st of March. Should I consider that this date can be 20 or 22 in some other countries ? What are your advices on this problem ?
Let's say a user in New York sets a due date for a project as "anytime on Monday 26 January". That means "anytime from 0600 Monday 26 January to 0600 Tuesday 27 January" in Brussels and "anytime from 2000 Sunday 25 January to 2000 Monday 26 January" in L.A.
So completing the task at 2100 on Monday 26 is fine in Brussels and N.Y., but too late in L.A.
One possible work around is never just work with the date. If the time is not specified, either set it for 0000 hrs or 2400 hrs on the date specified in the timezone of the user.
The users may have to deal with strange due dates/times, but speaking as someone who used to work internationally, it kinda goes with the territory.
You won't be able to achieve what you are trying to do without storing the exact time. You simply don't have enough information.
When you don't have a time, assume that the time is the end of business in the main locale for the application, then translate that time as you would any other time. An alternative would be assuming end of the business day in local time and adjust that to UTC. Everyone using the application would need to understand whatever default time assumption you make when the time is not specified. Coordinating to the main office may be best in a large enterprise whereas coordinating to local time may be best in highly decentralized environments where the local context is equally important.
If you aren't storing the minutes and seconds you have to assume that the date being entered is the desired date and not to any adjustments for GMT. Just put it in the database as is. The people on the west coast will have to assume that the due date is the same regardless of where you are in the world. If you want to adjust for time zones, you'll have to collect more information, like hour, minutes, and seconds.
The easiest solution would be just to display as the same date for everyone. The deadline would then effectively be midnight in the latest timezone.
Otherwise, decide what the default time of the deadline should be in the timezone the task was created in, e.g. 21st March 17:00 EST or 22nd March 00:00 EST and display that in the local timezone. The timezone difference will then push it into the previous day or next day accordingly for the viewer.
SQL 2008 allows for a Date datatype that does not have any time value associated with it. That allows someone to say I need this done by this Date, but I don't care if it is +/- several hours. If the date selected is 1/1/2009 but it happens on 1/2/2009 at 2AM their time, they probably don't care.
When the user needs something done by a specific date and time, like close of business on 1/1/2009 then you need to store it in a DateTime as UTC and convert it to local time client-side.
This will take much of the complexity out of indicating when something is completed, it'll either be completed near a specific day or by a specific time.
If you have a single instance of a DB, I would store all dates in the datetime timestamp of your DB server. If you are timestamping rows, consider GetDate() in T-SQL or as default value of the timestamped date column. Then you have your single reference point for all times. Consider UTC format there.
Then, all clients accessing the date do their own conversion into "local time" , which can be interpreted by things like : user preferences, date time stamp on client computer, etc.
Without knowing more, it hard to say exactly what the resolution is.
Your solution depends on your application and requirements.
I'd first store UTC + offset in your data structures, so it's easy to display for any timezone.
Most likely if a task or meeting is due at 12pm on 21/March in London then it will occur at 2130 on 21/March in Adelaide (+0930), but that is an application requirement not any sinister timezone related standard.
If you want the ultimate in flexibility, add a flag that can make the even due simultaneously in every timezone or at the same time no matter where you are (staggered) and show the event accordingly.
You might want to store the date in a from that is timezone aware. This will help you in your calculations. SQL Server 2008 for instance supports a datetimeoffset that does precisely this. Alternatively if you're using SQL 2005 with a bit of effort you can write your own SQL CLR data type to support this.