Re: timestamp with/without time zone
От | Thomas Lockhart |
---|---|
Тема | Re: timestamp with/without time zone |
Дата | |
Msg-id | 3B4BAD66.68C6A8BD@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: timestamp with/without time zone (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: timestamp with/without time zone
(Bruce Momjian <pgman@candle.pha.pa.us>)
|
Список | pgsql-hackers |
> Is this a TODO item? Sure, but I'd hate to have all of these individual items showing up as separate things in some ToDo list, since it won't paint a coherent picture of where things are headed. I'm planning on doing some work on timestamp, which will include: o support for "ISO variants" on input, including embedded "T" preceeding the time fields o deprecation of 'current' (holdover from Original Postgres) o deprecation of 'invalid' for timestamp at least (holdover from Original Postgres) o (probably) deprecation of "ignored fields" if the value not explicitly recognized (holdover from Original Postgres) o resolution of the SQL99 vs SQL-useful timestamp and timestamp with time zone issues The latter has two possible outcomes (maybe more): a) we keep the current timestamp implementation as either timestamp or timestamp with time zone, and implement the other as a new type with much common underlying code b) we roll back decisions made a few years ago, and have "SQL-useful timestamp" become datetime, leaving timestamp with time zone and timestamp with slavish SQL99 compliance as undersupported, ineffective and near-useless data types (an overstatement for simple timestamp, but not for timestamp with time zone). For those who haven't used a fully compliant timestamp with time zone (and most haven't, since it is brain damaged) the time zone is specified as a single offset from GMT. No provisions for DST, etc etc. The current identification of timestamp as "timestamp with time zone" was to prepare for implementation of a "no time zone anywhere" timestamp in 7.2. The current timestamp would become "timestamp with time zone", with time zone support substantially enhanced from SQL99 specs. I'll speak for the silent majority to claim that these enhancements are useful. They are likely compatible enough (or could be) to pass SQL9x compliance testing, unless that testing includes cases which try to enforce the worst aspects of the standard. Hmm, now that I look at it again, SQL99 timestamp with time zone may not be too far away from our current timestamp, except for issues concerning UTC vs local time and probably some other details of formatting and behavior (e.g. allowed date ranges; we allow more). It appears that SQL99 timestamp with time zone outputs as UTC (which is how it is stored internally already) so the standard is missing the notion of representing time zones in the output of a timestamp or timestamp with time zone type. This is not as horrendous as SQL92 or as described in some draft standard docs, but... Comments? - Thomas
В списке pgsql-hackers по дате отправления:
Следующее
От: michael@miknet.net (Michael Samuel)Дата:
Сообщение: Re: Re: Encrypting pg_shadow passwords