I'm using a scheduling component in a Joomla site that generates ICS files in the confirmation emails. The site and server are set to Los Angeles time zone. The users scheduling the appointments (and me testing it) are also in Los Angeles time zone. However the ICS file converts the appointment to 8 hours earlier than it should be when brought into iCal, Google calendar, and Outlook instead of keeping it to our local time zone.
The developer of the component is testing it from a different time zone 8 hours ahead of mine. He says when he books from my site, it converts correctly to his local time zone and he doesn't see any problem with the ICS file.
This is the code in the ICS file. Is there an issue here that I can pass on to the developer that could be causing it to convert correctly when in different zones, but incorrectly when it's supposed to stay the same time zone?
BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
UID:61d73f89b2993
DTSTART;TZID=UTC:20220113T163000Z
DTEND;TZID=UTC:20220113T164500Z
DTSTAMP:20220113T163000Z
ORGANIZER;CN=Clark County Composts:mailto:Pete.Dubois#clark.wa.gov
CREATED:20220106T191417Z
DESCRIPTION:Peter DuBois From: 4:30 PM To: 4:45 PM \nPhone or Zoom: Zoom
LAST-MODIFIED:20220113T163000Z
LOCATION:Virtual Consult
SUMMARY:Training Consult
SEQUENCE:0
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
Thanks
Karen
Two points:
Firstly, DTSTART;TZID=UTC:20220113T163000Z is invalid. One uses either the Z suffix OR TZID, not both at the same time. See the 3 forms of datetime specification for RFC5545 at https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.4. You can also use (use all as they differ) the various ICS validators.
Secondly it is perfectly OK to issue the ics in either UTC or Z format. Any receiving application should deal with the timezone changes correctly depending on the timezone settings of the user. Usually when a user says it's wrong, they haven't realised that their app maybe has a different timezone and/or they have forgotten about daylight saving.
Related
I've recently taken over some accounting responsibilities at my workplace. Office payroll is due on the 10th and 25th of each month, but in order for the money to arrive on time, it must be processed at the very latest by 5:00 PM two business days prior to the last business day on or before these payroll due dates. How can I set something like this up in Google Calendar?
I've been reading up on iCal import tweaks (create an iCal file and import it instead of making the event in gCal, to have more flexibility) but can't find a way to subtract a number of days (or business days at that).
VERSION:2.0
BEGIN:VEVENT
RRULE:FREQ=MONTHLY;INTERVAL=1;BYSETPOS=-2
SUMMARY:Pay Office Staff
DTSTART;VALUE=DATE:20190815
SEQUENCE:0
DESCRIPTION:Send office payroll.
END:VEVENT
END:VCALENDAR
I have no idea how to make it work except to do the date math in a Google Apps Script and have it create the events each month. I'm hoping someone can direct me to where I can find more information about how to achieve my desired result. I expect when it's done (if even possible) that I'll have a recurring event that takes place 2 business days prior to the last business day on or before the the 10th and another for the 25th.
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'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.
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.