I'm having issues with my webserver and iPhone app, considering the timezone. It's all set well and I know how to change it, but I'm just wondering what is the best approach considering the following case.
The iPhone app I am working on uses several NSDate objects to store datetime values. These get exchanged with the webserver (including database) that uses timestamps for comparing dates. For exporting the NSDate object I usually convert it to a string by formatting NSDate timeIntervalSince1970. I don't know what the exact timezone of this interval is, but I'm guessing it's the locale (if not set otherwise).
My webserver is set to CET (UTC-1). When the iPhone app converts the interval to, say, UTC-3, and the database compares it with a UTC-1 date, you obviously get a gap.
What's the best approach here? How does timeIntervalSince1970 handle timezones? I'm well aware that NSDate has no timezone (a timezone is merely representation), but since I'm converting from and to unix time through a string, I think it matters.
Any help is greatly appreciated.
Kind regards,
Reinder
Just always use UTC time. Both on client and server.
Yes, I would agree with the previous post to keep the server and iPhone database on the same timezone (UTC). I would only mess with the different timezone when actually displaying something on screen such as in a UITextView, when you would use the local time. So if someone in Sydney sync'ed with the server at the same time as someone in London, the server and both their iPhone's database would have the same datetime stored, but would display different times.
Related
A mobile app has a check-in feature for the user to send a photo and observation and the app will append his location, date and time to the request, and send it to the server.
It is extremely important that this date and time is not faked by the user, or else the user will be able to be late at work but check-in with a fake "15 minutes ago".
The server is in USA, and the users are in many countries so there are different date and timezones, for that reason I think I can't use server date and time.
That check-in is visible in a website to users all around the world, but the check-in time must be the one from the user who made it.
Example
User checks-in at 5th July 13:45 in Mexico.
Website should show this date and time, 5th July 13:45, even if it's visualized by someone in Japan.
Problem
User checks-in at 6th July 09:37 in Brazil, but he fakes his mobile date and time settings to say it's 6th July 09:00 to pretend he's not late for work.
How can the sever know it's actually 6th July 09:37 and not 09:00, and show that correct date and time to whoever sees it anywhere in the world?
Keep in mind that user can also fake his timezone and GPS, still the server needs to get the real timezone to show real and not mislead information.
It is extremely important that this date and time is not faked by the user, or else the user will be able to be late at work but check-in with a fake "15 minutes ago".
This part is best handled by taking a UTC timestamp from the server when the request is received.
The server is in USA, and the users are in many countries so there are different date and timezones, for that reason I think I can't use server date and time.
Time zone is irrelevant for this purpose. Get the UTC time from the server, not the local time. The local time of the server should not ever be used in your application code.
If you need to adjust it to a particular time zone, then you can collect that from the user in a variety of ways, or you could assign one permanently to the user by some administrator of your application. Even if the time zone is wrong or faked, it won't affect the duration of time worked - because you captured that in UTC.
Example
User checks-in at 5th July 13:45 in Mexico.
Website should show this date and time, 5th July 13:45, even if it's visualized by someone in Japan.
That's fine. Save that the user is in Mexico (... actually, Mexico has several time zones, so you'll need to be more specific - use an IANA time zone identifier). You can convert the UTC timestamp to Mexico time whenever you like - either when you recieve the timestamp (saving both UTC and Mexico time), or when you display it to the user (saving only UTC and converting to Mexico time at the time of display). That the user is in Japan is also irrelevant to this scenario.
Problem
User checks-in at 6th July 09:37 in Brazil, but he fakes his mobile date and time settings to say it's 6th July 09:00 to pretend he's not late for work.
That's not an issue if you capture the time in UTC at the server and make sure your server's clock is synchronized properly.
Keep in mind that user can also fake his timezone and GPS, still the server needs to get the real timezone to show real and not mislead information.
Indeed. You can't capture this information from the user in a way that can't be falsified. However, you can avoid relying on this in your application code. For pure duration calculation, just base everything on UTC. For more complex things (like determining shift differentials or daily overtime working over midnight or at other peak local hours, etc.) then have some other user set the time zone that's applicable rather than collecting it. For example, assuming these are employees, the employee's manager or HR department would assign a time zone to the employee's personnel record.
Of course, if the employee is traveling for their job, and local time rules apply differently in different time zones, then you have even more logic to think about how you capture such details. (My experience tells me this is rare.)
You can't do what you want to do. Your app relies on the mobile device's OS to get things like date, time, timezone and gps. While it's harder to fake gps data on out of the box OS's it's always going to be possible. What you really want is a "backdoor". A backdoor that will let you get to the user device's "real" information no matter how hard the user tries to hide it. If that were possible we wouldn't need/have hackers and government cyber security teams. Anyone who knew the backdoor could just find anyone else in the world.
You can only try to catch such abusers using some of your own measures. You can check if the users time zone is changing. Or using an ip address from a different country since the last time he/she used the app. Or if you're really going to ask for gps permission, you can also see if that person's location over time doesn't make sense (E.g the user was in Canada but 3 hours later it looks like they're in China). Once you detect such possible abuse, you can flag the account for human review.
This is the scenario:
I'm writing a medical related program, that would be use while with no connection. When some action act, the program would write the time to CoreData record.
That's the problem, if their device set the time to a diff time like earlier than the real time. That would be a big problem coz it's for medical usage.
So, how can i get the "real" time even if there is no connection?
Or, is it possible to disallow user changing the device time using something like restrictions or DeviceProfile?
It's only because Apple IS the Big Brother they claimed to be fighting in 1984. Welcome to 1984! Otherwise we would have access to real time time, and an English version of ISO date format! :-/
Every iPwn, and now other devices, has a GPS receiver and an Internet capability, from which sub-second accurate time could be derived, yet Apple insists on forcing us to depend on AT&T to automatically set our clocks. It's only recently that AT&T started delivering accurate time, thank god for small favors.
The lack of GPS and NTP time setting, plus the glaring omission of ISO 8601 date formatting with otherwise USA formats and language, is extremely annoying on a daily basis.
So, the answer to your question is, Yes, it is feasible, but not in Apple's Jail, since you cannot set RTC from GPS or NTP without jail breaking.
PS: my guess is that AT&T insists on this for call-timing or something stupid that has to do with charging us more money! ;-)
You get the real time from [NSDate date]. For example, the following:
[[NSDate date] timeIntervalSince1970]
gives the number of seconds since 1/1/1970 midnight UTC. This is independent of timezone and independent of whatever time is set by the user. If you know the timezone, then you can convert that to local time with the NSDateFormatter if you like, but make sure to also record the timezone to make the representation unique.
EDIT: Sorry, this answer is actually not correct. After trying it out, it appears that setting the time by the user also changes the NSDate values.
So, how can i get the "real" time even if there is no connection?
If by "no connection" you mean "no network connection of any sort" the answer is that you can't.
I think the best you can do is disable the functionality if you can't find a way to independently verify the system time (and tell the user why).
NSDate and all associated classes read the date from the system time. Without an internet connection to refer to, the NSDate class is open to user abuse.
I used an example in a comment on fishinear's answer of Farmville. If the user plants some crops that take five hours to grow, you can just change the system time to five hours in the future to harvest. Which, I'm sure, is one of the reasons that Zynga requires an internet connection to play their games.
Without some time-telling hardware, Apple cannot realistically tell time without an internet connection; even if they did have some amazing solution, they'd have to take into account timezones and even travel across timezones in order to make this work.
If I were you, I'd require an internet connection at specified intervals (once a day or the like) in order to draw a reference.
Let us know why you need this and we may be able to suggest some viable alternatives in function.
I am working with Unix timestamps, but I get a different time on my Android phone and my computer than the time given on http://www.unixtimestamp.com/index.php
The time difference is one hour (give or take a few seconds probably, didn't ever design an extremely accurate test).
I thought that the Unix time was the same everywhere on earth (or perhaps the universe, but that brings up questions of frames of reference and velocities that I don't even want to think about).
Basically my question is, what is going on here? I get the time on the Android device using Date date = new Date(); long now = date.getTime(); (I account for this having milliseconds btw) and I connect through putty to a linux server and the time is the same (obtained by date +%s). It's just the website that disagrees on the time, and since I don't know too too much about Unix timestamps and the site looks legit I wonder how this happened.
ps. I live in Saskatchewan, which doesn't observe daylight savings, but I don't see how that would really factor in. Does the website read the time from my computer maybe?
pps. sorry for rambling
That web site displays the wrong time.
The time zone handling on the iPhone seems a little confusing to me. As far as adding a new EKEvent to the device calendar it looks like you always just set the start/end times in local time, there is no timezone or offset we need to work with. Is this true?
I assume the device knows the time zone at the time the entry is made. The confusion comes in when you look at the device's Settings/Mail, Contacts, Calendars and scroll to the bottom for the time zone data. Whether to have time zone support ON/OFF, a set time zone, etc.
So if I am in California and add an event to the device and the time zone is set to "New York" and time zone support is ON, what time will the EKEvent actually show in?
Has anyone dealt with the iOS calendar via EventKit and have lessons to learn regarding time zone handling? Or is it straight-forward, just use the local time and enter the event and the device will take care of the rest?
Thank you.
NSDate don't have a timezone, they're in UTC (AFAIK). If you need to convert from/to a certain timezone, use NSCalendar. I suppose Mail and friends need explicit timezone handling for dates coming from external sources.
hi i am making an app in which user sends xml to server and get response....
now i have to save the date and time of sending and response of that request....for this should i use iphone's date or check it online?
because my thinking is that the iphone's date and time may not be correct.....always...so it is better to check the time online ....
i know the local part but need help regarding online check....please help
Just use the local time. It will save you a lot of trouble and work. Or is your app so absolutely dependent on the correct time, like to display the current position of the sun or something ? If not, the local time is likely "good enough".
If you need the same time as the server, then it would seem that you need to establish the offset between server time and local time, and then you can adjust your local timestamp.
Is there a way to get the (current) time from the server?
Assuming the timestamp you're saving is for the request sent from the iphone and the response received by the iphone, then it would actually seem logical to use local (iphone) time.
You could always use NTP (http://en.wikipedia.org/wiki/Network_Time_Protocol) to get the current time, but that doesn't guarantee the time is thesame as the server.
You usually don't need absolute time of some sort, just the same time source as your server and your server's database.
So compare your local time with whatever the server thinks the time is and adjust accordingly.