Re: timestamp with/without time zone
От | Thomas Lockhart |
---|---|
Тема | Re: timestamp with/without time zone |
Дата | |
Msg-id | 3B336774.99A142A7@fourpalms.org обсуждение исходный текст |
Ответ на | Re: timestamp with/without time zone (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: timestamp with/without time zone
Re: timestamp with/without time zone |
Список | pgsql-hackers |
> I already commented what I thought about this: the current type is not > either of the SQL-compatible timestamp types, and if we want to support > the SQL-compatible semantics then we need three types, not two. Right, that was clear even to me ;) We were on that path for quite some time. I volunteered to move the datetime type to become timestamp since *no one* was interested in implementing timestamp properly. There was extensive (or at least complete) discussion at the time. Per Date and Darwen (and common sense) the SQL9x date/time time zone support is fundamentally flawed, and clearly leads to deep trouble in trying to operate a database across time zones or national boundaries. PostgreSQL had strongly influenced SQL standards in the past (e.g. data type extensibility) and imho our current implementation is the way the standard should have read. > I believe everyone already agreed that 'current' should be removed. > 'invalid' seems somewhat redundant with NULL, so I wouldn't object to > taking it out; on the other hand, is it hurting anything? Also, it > seems a bad idea to remove it from timestamp if we leave it in abstime; > you shouldn't have to worry that casting abstime up to timestamp might > fail. I wouldn't worry about that, since we can now return NULL in the translation of abstime to timestamp. otoh we could choose to do the same for abstime itself, so 'invalid' is not fundamentally necessary for that type anymore either. - Thomas
В списке pgsql-hackers по дате отправления: