0

Consider an application like Uber. It operates in multiple cities in multiple time zones. Sometimes the user can book a cab for a friend in another time zone. The DB servers are again distributed in several locations. You can have multiple APIs in between which again have their own servers with their own timezones.

Is enforcing the use of UTC in every software component the only reliable solution? What if a version using local time makes it to production by mistake?

I am interested in knowing the best practices when it comes to storing date-time values.

Katana
  • 401
  • 3
  • 22
  • I think it's more complex than it's often represented - to an extent that makes a really good answer here too longwinded to give. One example to consider, as a counterpoint to Sereja's answer: imagine you're planning for a meeting in 5 years, at 9am local time in some specific time zone. You right it down as "9am" in your long-range hard-copy calendar, and add it to the electronic calendar. Then in one year, the time zone rules change - it happens. If you've only actually stored the UTC instant and offset, you can't take that change into account to keep your event at 9am. – Jon Skeet Feb 05 '18 at 10:47
  • (There was a good blog post about this a while ago, but unfortunately I don't have it to hand.) Fundamentally, you should think about what the information you've got really means. – Jon Skeet Feb 05 '18 at 10:48

1 Answers1

0

There is actually no choice. You have to introduce some kind of "base time", typically UTC (but depends upon particular needs) along with a properly tested yet reliable "relative system" (which might be as easy as specifying +/- with respect to the UTC time). Such a solution would indeed satisfy all the needs you mentioned and proved to be "best practice" for such apps like market-trading account systems, where the date and time is one of the most valuable factors.

Zazaeil
  • 3,900
  • 2
  • 14
  • 31