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)?
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.
I just came across this answer which simply states that "Time stamps use UTC."
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?
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.