14

I have a web app with an ASP.NET API back-end and React front-end. It also has a mobile app built in React Native.

Question is about date/time values. I have two options in handling time zone conversions and wanted to get some opinions on which is a better approach.

  1. I can store user's time zone in the database and send all date/time values already converted to user's time zone -- based on the saved time zone data. The advantage of this approach is that the front-end doesn't have to do any work. This is an advantage especially for older smart phones with limited system resources.
  2. Second option is to send UTC values to the React front-end as well as the mobile apps and let JavaScript handle the work of displaying date/time values based on user's time zone that it captures in runtime. The advantage of this approach is that JavaScript captures the user's time zone in real time and can be more precise. For example, user may tell me that he/she is in US Eastern Time Zone but then travel to California i.e. US Pacific Time Zone. I guess letting JavaScript handle the time zone data may eliminate the worry created by user traveling to another time zone.
Improve this question

3 Answers 3

Reset to default
11

The general rules is 'Always send date times as UTC' and only convert on the presentation layer.

However, javascript is rubbish with datetimes. So I would do the required conversion server side and send BOTH.

You need the UTC in case you want to order items by time or do any manipulation of the data like 'add one hour' without worrying about daylight savings and the like.

In fact you probably want to send UTC, local time, users local time and localised string versions of those. Treat any client side stuff as presentation layer

Improve this answer
3

I think this can be framed not just as an ASP/React issue, but a general issue concerning server/client interaction.

You should attempt to answer the following questions:

  • How much does the time zone actually matter to your clients? Is it a delivery service where time is crucial, or is it a photo editing website where time is more disposable?

  • As a corollary to the above, is it safe enough to auto-detect the client's time-zone, or is the time-zone so crucial that it should always be made an explicit option set by the user?

  • Is the time zone so important that your clients may need to display the time in multiple zones? e.g. have the server store the client's default timezone; and then if the client reports that it has detected a timezone move, offer to the user that the time be displayed in both local and default zones.

  • How often is the client expected to move around? Is the client on a transport truck, or is it a server in some data warehouse?

I think the answers to these questions should help you weigh the cost (development time, maintainability, complexity) versus the benefit.

Improve this answer
3

With time and time zones experience has told me that you want to minimize the number of different places where the same thing is done.

  • Single source of "now". If you need the current time on the client, ask the server. This gets rid of a whole class of "off by a few minutes" errors.

  • Single source of time zone rules. I prefer to do time zone conversions in the server, consistently from the same TZ database, so that there can be no odd differences because one part of the system has had a TZ database update and the other has not.

  • Single way to represent time. I prefer ISO timestamps, because they include both offset and date and time in a readable way.

A key thing to take into account is that date+time+offset does not tell you which time zone is involved. A time zone is a calculation rule that when applied to UTC time gives you local time, but cannot be used in the other direction (because some local times occur twice or not at all, thanks to DST and other weirdness). So, in order to do time zone conversion you need (A) the date and time at UTC (or something reducible to UTC like datetime+offset), and (B) a time zone identifier. You can ship both of those to the client, but it tends to make API's ugly.

Improve this answer
5
  • You always store date time in UTC on the server side. You should always return back UTC. It's up to the consuming end - UI, B2B systems, to convert as they wish. You cannot always accommodate for all use cases. Always return back the raw data and let consumer deal with it as they wish.
    – code5
    Jul 18, 2019 at 14:15
  • @code5 Experience has told me otherwise. You store dates in timestamp with time zone fields, so that it is recorded what the offset was that the user entered the time from. Otherwise you're losing data that cannot be reconstructed reliably by the client. You return dates as ISO timestamps with offset so that the client can choose to use the offset (important for e.g. meeting room booking systems), or choose to convert it down to UTC.
    – Joeri Sebrechts
    Jul 19, 2019 at 7:30
  • that's the problem. We have users from all over the world looking and modifying data from different users in different timezones. Our systems are used by Airport Authorities looking at flight schedules from one timezone (station) to another. With just straight UTC, the consumer of the RAW data can display and any Timezone that suites their specific need and can switch as necessary. That's why it's called Coordinated Universal Time (abbreviated to UTC). We don't care what user updated the data in their TZ. Also, we have B2B systems that always assume UTC.
    – code5
    Jul 19, 2019 at 16:44
  • Well, in that case you won't get benefits out of the ISO timestamp+offset approach, because you only care about coordinated time and not wall clock time, but it still wouldn't be incompatible because all those offset-based timestamps are still reducible to UTC. In a previous job working on global booking systems I noticed that wall clock time and coordinated time weren't always the same thing, even though they should be, hence my preference for the offsets approach.
    – Joeri Sebrechts
    Jul 22, 2019 at 9:13
  • Consider that people can easily go on a business trip to another time zone. Now from London to Los Angeles wrong results will be noticeable wrong, but a one hour difference will go unnoticed until you miss your flight.
    – gnasher729
    Jan 23 at 8:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.