On Fri, Nov 01, 2013 at 04:51:34PM +0000, Tom Lane wrote:
> Remove internal uses of CTimeZone/HasCTZSet.
>
> The only remaining places where we actually look at CTimeZone/HasCTZSet
> are abstime2tm() and timestamp2tm(). Now that session_timezone is always
> valid, we can remove these special cases. The caller-visible impact of
> this is that these functions now always return a valid zone abbreviation
> if requested, whereas before they'd return a NULL pointer if a brute-force
> timezone was in use. In the existing code, the only place I can find that
> changes behavior is to_char(), whose TZ format code will now print
> something useful rather than nothing for such zones. (In the places where
> the returned zone abbreviation is passed to EncodeDateTime, the lack of
> visible change is because we've chosen the abbreviation used for these
> zones to match what EncodeTimezone would have printed.)
This changed EncodeDateTime() output for USE_SQL_DATES and USE_GERMAN_DATES
styles, because it inserts a space before "tzn" but does not insert a space
before EncodeTimezone() output. Example:
set datestyle = sql,mdy;
select '2013-01-01'::timestamptz;
old output:
timestamptz
------------------------
01/01/2013 00:00:00+00
new output:
timestamptz
-------------------------
01/01/2013 00:00:00 +00
I assume this was unintended.
> This could be back-patched if we decide we'd like to fix to_char()'s
> behavior in the back branches, but there doesn't seem to be much
> enthusiasm for that at present.
Note that for the corresponding scenario in Oracle, the "TZD" format code
yields blank and the "TZR" format code yields "-01:30". (Oracle does not have
a plain "TZ" escape.) So there's precedent for each choice of behavior, and I
don't see this as a back-patch candidate.
Thanks,
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
