Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>You have to store in UTC - if you don't, your historic reporting and behaviour during things like Daylight Savings goes... funny. GMT is a local time, subject to Daylight Savings relative to UTC (which is not).</p> <p>Presentation to users in different time-zones can be a real bastard if you're storing local time. It's easy to adjust to local if your raw data is in UTC - just add your user's offset and you're done!</p> <p>Joel talked about this in one of the podcasts (in a round-about way) - he said to <a href="https://stackoverflow.fogbugz.com/default.asp?W12621" rel="noreferrer">store your data in the highest resolution possible</a> (search for 'fidelity'), because you can always munge it when it goes out again. That's why I say store it as UTC, as local time you need to adjust for anyone who's not in that timezone, and that's a lot of hard work. And you need to store whether, for example, daylight savings was in effect when you stored the time. Yuk.</p> <p>Often in databases in the past I've stored two - UTC for sorting, local time for display. That way neither the user nor the computer get confused.</p> <p>Now, as to display: Sure, you can do the "3 minutes ago" thing, but only if you store UTC - otherwise, data entered in different timezones is going to do things like display as "-4 hours ago", which will freak people out. If you're going to display an actual time, people love to have it in their local time - and if data's being entered in multiple timezones you can only do that with ease if you're storing UTC.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload