问题
I'm looking for the best practice/solution to book a service internationally, using same time in any browser. I don't quite get the logic (and dug around here too).
Use case
- user in Brussels booking lets say a haircut service based in Singapore - he is flying there in a week. He picks 14:00 in the browser datetime control. The browser is, however, set to +1 UTC.
- SG haircut stylist should see the time in his agenda as 14:00 SG time.
- the barber shop owner is traveling at Dubai, and he wants to see his agenda still in SG timezone, despite his browser is temporarily set to +4 UTC.
Basically, all roles must see "barber shop" local time regardless of what TZ they are in, and report back to server in "shop" time.
Server time is UTC, timestamps are in unix seconds. "Shop" TZ is known.
Problem is that I use couple of jquery plugins (datetimepicker and calendar) that utilize browser local time internally, and there are a few thousand lines of code to analyze and fix, making it less supportable - browser in (Bruxelles|any other TZ) for each "new Date()" will get local browser time. There are quite some narrow places as well (as these imaginary "barber shops" are located worldwide and are picked from the map, so target TZ is dynamic).
What is the common practice for that?
Is it easier to
- mock "dynamic" base date in js that does not care of timezone, and feed to plugins
- convert server data to local TZ when loaded to the client
- apply some other solution
Thanks very much
PS I have read best practices - but as I said I'm sort of bound to using specific plugins.
SOLUTION:
I realized that I do not need relative values of these datetimes as I never need to compare books of different "barber shops" timewise (having lat/lng for each "shop" I can still recalc the relative times if needed).
Basically I would only need absolute UTC values regardless of the timezone and in this case unix time (seconds since 1970 UTC) fits perfectly.
Instead of correcting the time by user browser offset at the client, sending it to backend, and fixing it there by the target offset, now I run the whole system on clear UTC dates, both at client and server/db sides, stored and shown to all roles, with only exception to date/time filters, which are bound to local browser clock and not stored anywhere.
回答1:
There are a couple of ways you can go about this.
Option 1
- Forget about UTC, the browser's time zone, and the target time zone. Just treat them as unspecified datetimes.
- Between server and client, don't pass integer ticks or seconds - those are bound to UTC. Instead, pass local datetimes as ISO8601 strings, without an offset or a 'Z'.
Use moment.js to parse and format the strings without introducing the browser's offset. For example:
// to get a Date value suitable for use with an existing control or script. var date = moment('2013-04-19T14:00').toDate(); // to get a string back from a Date that's ready to go to your server. var str = moment(date).format('YYYY-MM-DDTHH:mm');On the server side, it depends what platform you are on. Probably ISO8601 is already supported. For example, in .Net it is simply
.ToString("o"). If you need specific advise on this, please tell us about your server platform/language.
Option 2
- Transfer UTC datetimes to/from your server using ISO8601 with its 'Z' specifier.
- Any time you work with the date, use a TZDB javascript library such as one of the ones I listed here. Convert to/from UTC and the target time zone - ignoring the browser's time zone.
- This will work just fine, and now you're talking about a specific moment instead of some unspecified local time. However, those libraries require a lot of data and that is probably overkill for such a simple task. I don't recommend this unless you have many other conversions to do, such as converting the appointment time to other time zones.
来源：https://stackoverflow.com/questions/15981131/same-datetime-across-timezones-in-browser-on-a-booking-engine