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

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.

Comment on Re^4: DateTime Invalid local time for date in time zone Select or Download Code

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]