I my app, I am reading time zone by
[[NSTimeZone] localizedName]
It works for most of the cases. However the iOS the one displayed is not necessarily the one read from settings. For example, if we set time zone to "Phoenix, U.S.A.", when we read it, it's "Mountain Standard Time".
The question is: Is there a way to get the display time zone name?
There is a [NSTimeZone isDaylightSavingTime] can be used to differentiate the 2 time zones.
Related
I have the following the scenario...
I want to set an alarm for myself on my mobile device for 30 days from today (at noon). I also want to do the same for a number of other people in a number of different timezones.
I DON'T want to convert 30 days at noon MY local time into whatever their local time is. (I'm on US Pacific time - I DON'T want US East Coast users to experience the alarm at 3PM.) Instead, I want those others to experience the alarm 30 days from now at noon THEIR local time.
So what is the best practice for storing this type of date/time information? Storing UTC doesn't make sense here. In these cases, do people typically just store the date and time in strings and then use those to generate local times on local machines?
Indeed, it sounds like you should keep track of simply the date and time that you want the event to fire, either with respect to the end-user's time zone - or perhaps without a time zone at all (to infer their local zone).
This has been covered before, several times such as here.
You didn't indicate what programming language or database environment you are using, but in general you shouldn't store date/time values as strings, but instead you should use a data type appropriate for the scenario you are in. Some of them may be UTC-based, but many are not.
I am having a miserable time with dates/times in one particular app. It's an event booking app, where I don't even want to know that there is such a thing as timezones. I want one time and only one time, regardless of where the user is currently located. I don't EVER want the time converted to any other locale/timezone. There is no such thing as "local" time in this app, as everything is based on the time for the location where you booked the event. It needs to always be expressed in that time, not the time where you currently are. As such, I don't really need any timezone features.
For example, you are in New York and you book an event/appointment in London for 10:30 pm on March 15. Now, regardless of whether you are in New York, London, or any other city in the world, that event is still at 10:30 pm on March 15 in London. If you're on vacation in Los Cabos, you DO NOT want to know that your event is at 3:30 pm Los Cabos time.
Before anyone explains to me that NSDate does not contain timezone data, I am completely aware of that, and that info is useless to me. An NSDate may have no timezone info, but the dates get converted thousands of times, and every conversion takes the timezone into account, causing me great misery. I have about 30 extensions on NSDate, trying to make sure it NEVER returns a local time (try to keep everything at UTC). Thought I had it beat, but apparently the DatePicker has it's own date formatter, so all of the date pickers now screw up.
There MUST be a way to deal with this in a relatively simple way. I tried dealing with everything as UTC dates, from the remote database to the web services to everything in the iOS app, making sure that everything converted to/from strings, etc. stays in UTC format. Still not having much luck. I can create an elaborate animation in minutes, but I've been fighting with these stupid dates for weeks.
What is the best way to approach this?
Everything in one time zone (e.g. UTC)
Force app local time zone to be same for everyone?
Store time in time zone of event location, then always try to display it based on that timezone? This sounds complicated but I'm afraid it's the direction I should take, even though it's overkill.
Create date formatter and reset locale every time I touch a date?
Other?
Here's the thing. Ignore timezones except for two actions in your app:
When showing dates/times to a user.
When getting dates/times from a user.
Once you have an NSDate, forget timezones exist. Persist NSDate as-is. Do calculations with NSDate as-is. In a sense, this means everything is done in UTC time. It's all consistent. It's all uncomplicated.
You only worry about timezones when showing those dates to a user or when getting them from a user. That's it.
If you want the user's locale time, just use NSDateFormatter and its default timezone to show or get local times.
If you want to show or get times specific to an event, use an NSDateFormatter with its timezone set to the timezone of the event.
It's not any more complicated than this.
It always seems more complicated I think because people start logging NSDate and see what looks like the wrong time because they don't realize the output of the NSLog is in UTC time, not local time.
For example, you have a UIDatePicker for an event in London. Set the date picker's timezone to London time. Store the resulting NSDate. When you want to show the event's time to the user, set the timezone of the NSDateFormatter to London time. Then, no matter where the user is, it will show the proper London time.
The scenario is a iPhone user who doesn't want the time to automatically update when he travels abroad and thus has disabled the system setting "Set Automatically" for time zones, leading to [NSTimeZone systemTimeZone] not updating for his new location.
As a developer, can I still find out the current local time and time zone for the (possibly new) country the device is in?
No. Not without some work anyway, and maybe not with some work.
If the user has disabled auto time zone setting, the only time zone you get to know about is the one that they've told their phone to use. You don't get to bypass their preferences on that. Unfortunately you also don't get to find out if they've done that. All you get is a time zone, but why that's current is not something you can answer.
If you're determined, you might try using Core Location to get their latitude and longitude, and work out a time zone from that. Doing that reliably may be a challenge-- the official IANA time zone database includes lat/long, but only at one location within each time zone. There are services like AskGeo that claim to solve this problem (they might be fantastic, I haven't tried them). But that obviously requires a network connection, and people traveling to other countries are probably less likely than average to have mobile data access.
Am developing website like online travel portal. The issue is displaying GMT time for various regions at flight booking and list out the timing. Any one gives idea to calculate and show the time for different countries?
Thanks
Although it is pretty hard to answer your question without a reference to particular technology, I will try.
End user Time Zone detection
Definitely, all time-related information should be presented both in local format and local time zone. By local I mean the one used by end user.
I am guessing that your application will not require creating user profiles. I am also assuming that flight schedules will not be visible on front page and user would need to perform search. In that case you have three choices:
Let user specify time zone from drop down box. I have no way to show you how it should be done without referring to concrete technology. The only thing I must point out is, it should present UTC offset, time zone name and list of cities, for example: UTC+01:00 Central European Time (Paris, Berlin, Warsaw).
You could read current time zone offset with JavaScript and send it out to server
In that case you can use following code snippet to detect offset:
var now = new Date();
var offset = now.getTimezoneOffset();
This will give you current GMT offset in minutes. The problem with that solution is, this offset might be different on the target date.
Obviously you could as well send GMT based dates in invariant form to the browser (for example using ISO8601 format: 2011-05-25T11:07Z) and format this date on the client using JavaScript. I never heard of for example JQuery plugin which would do that correctly (respecting local formats), though. It seems that you would be forced to write your own.
Date and time formatting as well as time zone conversion
Ha, it depends on solution you want to implement as well as technology you want to use. For now, I can't write much here.
I have to write some code working with timezones. Is there a good introduction to the subject to get me started?
Also answered at What every developer should know about time (which includes the referenced screenshots).
With daylight savings time ending today, I thought this was a good time for a post. How to handle time is one of those tricky issues where it is all too easy to get it wrong. So let's dive in. (Note: We learned these lessons when implementing the scheduling system in Windward Reports.)
First off, using UTC (also known as Greenwich Mean Time) is many times not the correct solution. Yet many programmers think if they store everything that way, then they have it covered. (This mistake is why several years ago when Congress changed the start of DST in the U.S. you had to run a hotfix on Outlook for it to adjust reoccurring events.)
So let's start with the key question – what do we mean by time? When a user says they want something to run at 7:00 am, what do they mean? In most cases they mean 7:00 am where they are located – but not always. In some cases, to accurately compare say web server statistics, they want each "day" to end at the same time, unadjusted for DST. At the other end, someone who takes medicine at certain times of the day and has that set in their calendar, will want that to always be on local time so a 3:00pm event is not 3:00am when they have travelled half way around the world.
So we have three main use cases here (there are some others, but they can generally be handled by the following):
1.The same absolute (for lack of a better word) time.
2.The time in a given time zone, shifting when DST goes on/off (including double DST which occurs in some regions).
3.The local time.
The first is trivial to handle – you set it as UTC. By doing this every day of the year will have 24 hours. (Interesting note, UTC only matches the time in Greenwich during standard time. When it is DST there, Greenwich and UTC are not identical.)
The second requires storing a time and a time zone. However, the time zone is the geographical zone, not the present offset (offset is the difference with UTC). In other words, you store "Mountain Time," not "Mountain Standard Time" or "Mountain Daylight Savings Time." So 7:00 am in "Mountain Time" will be 7:00 am in Colorado regardless of the time of year.
The third is similar to the second in that it has a time zone called "Local Time." However, it requires knowing what time zone it is in in order to determine when it occurs.
Outlook now has a means to handle this. Click the Time Zones button:
And you can now set the time zone for each event:
When I have business trips I use this including my flight times departing in one zone and arriving in another. Outlook displays everything in the local timezone and adjusts when that changes. The iPhone on the other hand has no idea this is going on and has everything off when I'm on a trip that is in another timezone (and when you live in Colorado, almost every trip is to another timezone).
Putting it to use
Ok, so how do you handle this? It's actually pretty simple. Every time needs to be stored one of two ways:
1.As UTC. Generally when stored as UTC, you will still set/display it in local time.
2.As a datetime plus a geographical timezone (which can be "local time").
Now the trick is knowing which to use. Here are some general rules. You will need to figure this out for additional use cases, but most do fall in to these categories.
1.When something happened – UTC. This is a singular event and regardless of how the user wants it displayed, when it occurred is unchangeable.
2.When the user selects a timezone of UTC – UTC.
3.An event in the future where the user wants it to occur in a timezone – datetime plus a timezone. Now it might be safe to use UTC if it will occur in the next several months (changing timezones generally have that much warning - although sometimes it's just 8 days), but at some point out you need to do this, so you should do it for all cases. In this case you display what you stored.
4.For a scheduled event, when it will next happen – UTC. This is a performance requirement where you want to be able to get all "next events" where their runtime is before now. Much faster to search against dates than recalculate each one. However, this does need to recalculate all scheduled events regularly in case the rules have changed for an event that runs every quarter.
1.For events that are on "local time" the recalculation should occur anytime the user's timezone changes. And if an event is skipped in the change, it needs to occur immediately.
.NET DateTime
Diving in to .NET, this means we need to be able to get two things which the standard library does not provide:
1.Create a DateTime in any timezone (DateTime only supports your local timezone and UTC).
2.For a given Date, Time, and geographical timezone, get the UTC time. This needs to adjust based on the DST rules for that zone on that date.
Fortunately there's a solution to this. We have open sourced out extensions to the DateTime timezone functionality. You can download WindwardTimeZone here. This uses registry settings in Windows to perform all calculations for each zone and therefore should remain up to date.
Browser pain
The one thing we have not figured out is how to know a user's location if they are using a browser to hit our web application. For most countries the locale can be used to determine the timezone – but not for the U.S. (6 zones), Canada, or Russia (11 zones). So you have to ask a user to set their timezone – and to change it when they travel. If anyone knows of a solution to this, please let me know.
Update: I received the following from Justin Bonnar (thank you):
document.getElementById('timezone_offset').value = new Date().getTimezoneOffset();
Using that plus the suggestion of the geo location for the IP address mentioned below will get you close. But it's not 100%. The time offset does not tell you if you for example if you are in Arizona (they & Hawaii do not observer daylight savings time) vs Pacific/Mountain (depending on DST) time zone. You also depend on javascript being on although that is true for 99% of the users out there today.
The geo location based on IP address is also iffy. I was at a hotel in D.C. when I got a report of our demo download form having a problem. We pre-populate the form with city, state, & country based on the geo of the IP address. It said I was in Cleveland, OH. So again, usually right but not always.
My take is we can use the offset, and for cases where there are multiple timezones with that offset (on that given day), follow up with the geo of the IP address. But I sure wish the powers that be would add a tz= to the header info sent with an HTML request.