16

I understand the best practice is to store UTC date/times in our database and display to the user in their local timezone. We'll store the timezone rather than the offset so we can support daylight savings time.

What way is best for handling timezones?

Option 1: Server speaks UTC only and client converts to timezone

All dates sent to the browser in HTML are in UTC. The client side will convert the UTC time to the correct timezone using moment.js or similar. The timezone specified in our database would be used rather than the browsers local time since that may be incorrect.

When the user submits a date or time, it must first be converted to a UTC time before being submitted to the server.

Option 2: Server converts to timezone

All calculations are still made in UTC and date/times are converted to the correct timezone at the last possible moment, for example when outputting the date in HTML.

When the client submits any date/times, it should be immediately converted to UTC.

Is there another way?

Community
  • 1
  • 1
Marcus
  • 9,011
  • 10
  • 45
  • 65
  • You should always set `UTC` from `htaccess` or from server `php.ini`. Also, in database the dates should be `UTC`. This way all the dates are the same. You can use `MySQL` and `PHP` to manipulate dates without the need to convert. The only conversion happens when you list the date to a user. – machineaddict Jul 09 '14 at 13:56
  • @machineaddict I'm asking if it's best practice to convert the dates on the client side or the server side. i.e. Do we make the server only speak UTC or should it also handle the timezone conversion? – Marcus Jul 09 '14 at 13:57
  • From method I explained above, the dates are handled completely from server side. So, the server talks only in `UTC`. – machineaddict Jul 09 '14 at 13:59
  • @machineaddict If the server talks only in UTC, then we rely on Javascript changing the date strings on page load? – Marcus Jul 09 '14 at 14:32
  • If your users are registered, they can choose their timezone. If the users are guests, you either change the dates with javascript to corespond to their computer timezone, show the server timezone or you can guess their timezone from their ip. One idea is to have a look how scripts like `vBulettin` or `phpBB` handles their time, based on user status (guest/logged-in). My next project has to be like this, so I will probably implement your best answer in it. – machineaddict Jul 09 '14 at 14:45
  • I prefer UTC on backend and timezone on front end using Moment.js package. Typically, if you want to convert timezone you want to do it according to the users local computer time which could be different for different users. Or you may want it user selectable. Either way, it makes more sense to do that on the user end knowing your one source of truth (the back end) will always be UTC. – fred Oct 23 '20 at 13:35

1 Answers1

19

Either option is valid, but there are advantages and disadvantages of each approach. There are several things to consider:

  • JavaScript's native time zone conversion is limited to the local time zone of the machine it is running on, and it is also seriously broken. If you plan to convert values in the client, you'll need one of the time zone libraries listed here. I personally recommend moment-timezone.

  • Converting values in the client (with any library) is going to require time zone data, which can be somewhat large if you want to support all of the time zones of the world. You may want to consider limiting the data to the minimal subset that meets your requirements.

  • Server-side time zone conversion also requires valid time zone data. PHP has this built in, and you can stay current with updates to the timezonedb package in PECL.

  • You also tagged your question with ASP.Net. .Net includes TimeZoneInfo, which offers support for Microsoft time zones only. If you want standard IANA time zones (like those used in PHP), then you will need a library. I recommend Noda Time. You can read more about the different kinds of time zones in the timezone tag wiki.

  • How you deliver the end result depends on what kind of application you are writing.

  • If you are creating a "traditional" web page, where the HTML is rendered server side, then you will be rendering a human-readable string. That means understanding not only the time zone, but also the user's locale so you can use a culturally appropriate format.

    This is not at all tied to time zone. For example, you might be and American using the MM/DD/YYYY format, but still be physically located in Europe and using a European time zone.

  • If your server is delivering results via an API (i.e. JSON, XML, etc.), then your results should be machine readable. Preferably, you should use the ISO 8601 format. Specifically, timestamps should be delivered as described in RFC 3339.

    This means that they should always include either a Z (for UTC values), or an offset (for local values). Therefore, you may take the user's time zone into account, but the result you deliver should include the local offset so it is unambiguous.

    For example, you have the UTC value 2014-07-09T12:00:00Z, then in America/Los_Angeles it's 2014-07-09T05:00:00-07:00 and that's what should be delivered over the API.

    On the client-side, you can render that value for the user with a library like moment.js. For example:

         var s = moment.parseZone("2014-07-09T05:00:00-07:00").format("LLL");

Related: How to properly work with Timezone?

Community
  • 1
  • 1
Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575