Re^2: DateTime Invalid local time for date in time zone

Replies are listed 'Best First'.
Re^3: DateTime Invalid local time for date in time zone by ikegami (Patriarch) on Jul 11, 2018 at 08:07 UTC
Alternatively, use the correct time zone (`-0800` instead of `America/Los_Angeles`).	[reply] [d/l] [select]
Re^4: DateTime Invalid local time for date in time zone by haukex (Archbishop) on Jul 11, 2018 at 08:59 UTC
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]
Re^5: DateTime Invalid local time for date in time zone by ikegami (Patriarch) on Jul 11, 2018 at 20:32 UTC
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]