Alternatively, use the correct time zone (-0800 instead of America/Los_Angeles).
-0800 (PST) is only the correct time zone at 2016-03-13 01:59:59. One second later, the correct time zone is -0700 (PDT). Except of course whenever DST and time zones are changed by law.
Using location-based time zone names (America/Los_Angeles) eliminates this issue.
| [reply]
[d/l]
[select] |
One second later, the correct time zone is -0700 (PDT).
No, PST doesn't suddenly stop existing because the laws change the official local time to PDT.
One second after 2016-03-13 01:59:59-0800 is 2016-03-13 02:00:00-0800 aka 2016-03-13 03:00:00-0700 (aka 2016-03-13 10:00:00+0000 and so many others).
So sannag is right that they could fix the time (2016-03-13 03:00:00-0700), but that's only one of the options. Fixing the time zone (2016-03-13 02:00:00-0800) is another.
It's quite common to store all times using a specific offset. Normally, that offset is UTC+0000, but that is by no means a requirement. A local power plant used EST (UTC-0500) year round despite local time switching between EST (UTC-0500) and EDT (UTC-0400).
Using location-based time zone names (America/Los_Angeles) eliminates this issue.
Clearly not. The OP had the issue while using America/Los_Angeles.
| [reply]
[d/l]
[select] |