I am looking for the best practice / solution for booking a service internationally, using the same time in any browser. I do not quite understand the logic (and dug here too).
Use case
- a user in a Brussels reservation allows talking about a haircut service based in Singapore - he flies there in a week. He selects 14:00 in the time control mode in the browser. However, the browser is set to +1 UTC.
- The SG haircut should see the time on its agenda as the time at 14:00 SG.
- the owner of a hairdresser shop travels around Dubai and he wants to see his agenda in the SG time zone, despite the fact that his browser is temporarily set to +4 UTC.
In principle, all the roles should be seen by the local time “hairdresser” regardless of what TZ they are in, and report to the server in the “store”.
Server time is UTC, timestamps are in seconds. "Shop" TZ is famous.
The problem is that I use a couple of jquery plugins (datetimepicker and calendar) that use the local time of the browser inside, and there are several thousand lines of code for analysis and correction, which makes it less convenient - the browser is in (Bruxelles | any other TZ ) for each new date () will get the local browser time. There are also rather bottlenecks (since these imaginary “hairdressing salons” are located all over the world and are selected from the map, so the target TZ is dynamic).
What is the common practice for this?
Is it easier
- mock a "dynamic" base date in js that doesn't care about the timezone, and feed with plugins
- convert server data to local TZ when loading to client
- apply another solution
Thank you very much
PS I read the best practices - but, as I said, I’m kind of obligated to use certain plugins.
Decision
I realized that I do not need the relative values of these dates, since I never need to compare books of different "hairdressing salons" with time (having lat / lng for each "store", I can still recalculate the relative times, if necessary) .
Basically I only need absolute UTC values, regardless of time zone, in which case the unix time (seconds since 1970 UTC) is perfect.
Instead of adjusting the time using the offset of the user's browser on the client, sending it to the backend and fixing it there using the target offset, now I start the whole system on clear UTC dates both on the client side and on the server side / is stored and displayed for all roles, only with the exception of date and time filters, which are tied to the clock of the local browser and are not saved anywhere.