Duncan Gillis <dgillis@dystillr.com> writes:
> I didn't intend on such an absurd timezone. The "-0400" came from a
> shell script of mine that set the timezone to an offset using using
> Unix's date command to print the local timezone offset (e.g., date +%z
> #=> -0400, if you're on the US east coast).
Ah so.
> The "+/-HHMM" timezone offset format -- without the colon between hours
> and minutes -- is quite common so it seems like this would be an easy
> error to make. Since a lot of developers interact with the database
> primarily through an ORM and as many (most?) ORMs apply their own
> localization conversion to a timestamp received from the database, a lot
> of people could have made a mistake similar to mine and never seen any
> ill effects. Then, all of a sudden 9.4 would appear to break their
> application.
Well, as I said, previous releases would have interpreted that as UTC
minus about two and a half weeks, so I'm not sure what you consider
an "ill effect" ;-). Accepting a plausible-looking setting and then
interpreting it in a totally insane way isn't that helpful IMO. But
I think we can content ourselves with throwing an error here, rather
than trying to restore the previous range of accepted values. If we
make it complain specifically that the UTC offset is out of range,
it might help people spot the problem pretty easily.
regards, tom lane