Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IOS Safari Converting the Time on the Date Incorrectly #93

Closed
davidmyers-a opened this issue Jun 15, 2020 · 2 comments
Closed

IOS Safari Converting the Time on the Date Incorrectly #93

davidmyers-a opened this issue Jun 15, 2020 · 2 comments
Labels

Comments

@davidmyers-a
Copy link

The times of events downloaded in iOS Safari browser are all off by a number of hours since the latest update.
I pin pointed it to the time.js code. When converting the date time from ISO format to the format used in ICS it seems unlike all the other browsers Safari on iOS is converting the javascript date but then adding the timezone offset automatically. Which means if a send the library a date of 2020-06-22T12:00:00 expecting it to be an event at 12pm it is converting it to 20200622T220000 which is 10pm (because I am in UTC+10).
This only happen on iphones, if i do it on Android Chrome or Desktop Firefox/Chrome then the date is fine. Additionally if i forward the invite to my iphone after creating it on the PC its fine, so its the creation of the date in the library.

Dunno how to resolve that other than instead of converting the the ISO date to a date object maybe just use regex to strip ou the '-' and ':' so it never converts the date sent. This would mean people could only send ISO format without timezone etc...
Date = Date.replace(/-|:/g, '');

Either way thought I'd raise the issue in case it impacts others.

@jshor jshor added the bug label Jun 17, 2020
jshor added a commit that referenced this issue Sep 25, 2020
This deprecates the usage of passing in ISO 8601 strings as dates. This
change fixes date-conversion and timezone issues #93, #104, and #107 by
providing the consumer with full control over the date and having
Datebook no longer mutate it.
jshor added a commit that referenced this issue Sep 25, 2020
This deprecates the usage of passing in ISO 8601 strings as dates. This
change fixes date-conversion and timezone issues #93, #104, and #107 by
providing the consumer with full control over the date and having
Datebook no longer mutate it.
jshor added a commit that referenced this issue Sep 26, 2020
This deprecates the usage of passing in ISO 8601 strings as dates. This
change fixes date-conversion and timezone issues #93, #104, and #107 by
providing the consumer with full control over the date and having
Datebook no longer mutate it.
jshor added a commit that referenced this issue Sep 26, 2020
This deprecates the usage of passing in ISO 8601 strings as dates. This
change fixes date-conversion and timezone issues #93, #104, and #107 by
providing the consumer with full control over the date and having
Datebook no longer mutate it.
@jshor
Copy link
Owner

jshor commented Sep 26, 2020

It appears that this issue affects multiple browsers unfortunately. Turns out that when the date is parsed as a string, the timezone won't be parsed if it's not passed in.

As of v4.1.8, you'll now be able to pass the start and end params as Date objects instead of strings, which gives you full control over the date and timezone

Note that passing dates as strings is still supported for backward compatibility, but will be removed in v5.0.0.

@jshor jshor closed this as completed Sep 26, 2020
@jshor
Copy link
Owner

jshor commented Sep 26, 2020

Just a heads up: v4.1.9 will correct date/time to enforce UTC -- in other words, the timezone that the user is in will be the timezone that is used in the calendars.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants