14

Should timestamps always use UTC (as in 2012-06-14T10:32:11+00:00) and not local time (as in 2012-06-14T06:32:11-04:00 for New York)?

References

  1. Although not a WordPress question, I believe it'll be a strong example -- the WordPress core, themes and plugins developed by the core developers, if outputting timestamp somewhere, always seem to use something like get_the_date('c'); or get_the_modified_date('c'); -- which always output timestamp in UTC, as in 2012-06-14T10:32:11+00:00.

  2. I just came across this answer which simply states that "Time stamps use UTC."

The question

Should timestamps be in UTC or is it just a recommended practise? (There's a lot of difference between the two.) Essentially is something like this -- 2012-06-14T06:32:11-04:00 -- wrong? How is 2012-06-14T10:32:11+00:00 better?

Community
  • 1
  • 1
its_me
  • 10,998
  • 25
  • 82
  • 130

1 Answers1

21

Timestamps should certainly be stored in UTC. How the date is formatted is dependent on the requirements for that timezone. Timestamps are generally stored in UTC so the conversion for display to other timezones is easier and possible.

By only storing timestamps as UTC in databases, you effectively make time zones a view concern only. All math and logic in regards to comparisons of times can be assumed to sync up world-wide. The rest is simply a matter of a client knowing where it's at, what the rules are for where it's at, and then just spitting out the result. In JavaScript via the Chrome developer's console for instance:

var dateObj = new Date();

console.log(dateObj);
// spits out local time
// if you and 23 other people in every time zone across the planet created
// a date object simultaneously you'd all see a different number
// adapted to your local time zones

var utcInMillis = dateObj.getTime();
// gives UTC in milliseconds.

console.log(utcInMillis);
// if you and 23 other people in every time zone across the planet created
// that same date object `dateObj` simultaneously you'd see the same number

console.log(new Date().getTime() - utcInMillis);
// how many milliseconds passed since utcinMillis was recorded and now

var utcAsDateObj = new Date(utcInMillis); console.log(utcAsDateObj); //and that's how easy it is to restore to a date //object from a UTC in millisecond format

Generally speaking, where there's modern web technology or similar options, the least painful thing to do is to store everything as UTC and then make time zones strictly a presentational concern. You don't need local time for anything but showing somebody time in the local context.

Even if you're stuck with some silly non-UTC timestamp on the back-end it's still worth making UTC your canonicalized option on the client-side by converting at point of entry and converting back at point of exit by whatever means possible. Sorting out time zones and in what places Daylight Savings Time was adopted and where its ignored is just way too much of a mess to DIY and it's typically inevitable if you actually have to touch the date object that you'll need to get a bit fancier with actually manipulating/comparing dates/times eventually.

There is no easier way to handle that than when everything is canonicalized as UTC in milliseconds right up the point before you spit it out on the page as a local time.

akinuri
  • 10,690
  • 10
  • 65
  • 102
tjg184
  • 4,508
  • 1
  • 27
  • 54
  • You do not answer my second question. Can you please take a relook at it? (if it wasn't intentional) – its_me Jun 14 '12 at 17:20
  • Oops, overlooked that one. I'm not sure I understand that question. – tjg184 Jun 14 '12 at 17:26
  • 2
    Sorry for the mad addition. Just ran into a giant PITA in our code base because somebody didn't understand this and wanted to spell out more why you should always freaking use UTC or at least something similar and easily converted to UTC for storage/transport. If you are storing time zones in your !@#$ing DB, stop, drop, RTFM on whatever date options you have. – Erik Reppen Aug 06 '13 at 00:01
  • Actually there might be legit reasons for time zones in your DB but never for comparison of stored times between two different locales. That's just bat-guano-confetti-crazy. – Erik Reppen Aug 06 '13 at 00:08