Trying to track down this problem I am having (as well as @sid), I have a page that displays a datetime from my database, the strange part here is that it works correctly for me on every single browser I test, and it works for 5 other people that have tested it, however I have one client, with Safari Version 13.1.3 (15609.4.1) and for her the time shows 2 hours before the database stored time.
I asked them to check on their same computer in Chrome as well as Firefox, and its perfect, and they also, checked on their iPhone and it was perfect too.
So it seems like its a particular version of Safari that is the latest in Mac OS Catalina with the July 15 2020 security update done.
My binding looks like {{event_date_selected.formatDate('dd MMMM, yyyy hh:mm a')}}
If anyone has any ideas of what could be causing this I would be super grateful.
To clarify this part, the two hours is because the user's local system's time is UTC+2.
The date time value si getting converted to whatever the local time of the user is, but only on this specific version of this specific browser.
If you need I can ask the client to check hers as well? One extra piece of info @sid used a custom formatter for this which first removes the Z then formats.
Sorry i am not sure i understand correctly. You have the date stored as UTC in your database: yyyy-mm-ddThh:mm:sssZ
So you remove the Z using a custom formatter and then it breaks in Safari?
It was broken in Safari 13.1.3 before the Z removal even took place, and worked before and after the Z removal in Safari 14 and upwards. So I do not think it has much to do with the Z removal to be honest. Sid would need to give more detail on that though.
The Z thing is actually just the Knex/NodeJS issue that has been discussed in a separate post. Time in DB does not have Z, Knex adds it.
But, that is not the issue here.
I am removing the Z and then applying the formatter.
But only on this specific version of Safari, its still getting converted to local time.
On the bright side @sid, at least I have a way for us to replicate the test internally so we don’t have to ask the client constantly, so we kind of one step closer, haha.
It sounds more like a bug in Safari, since other browsers don’t have this issue and it was solved in version 14. Will see if I can find more information about this issue.
