> So far, as compared to many other databases, PostgreSQL, remains
> pretty close to the standard (at least for our projects). The only
> areas that we have had issues with is the default inclusion of the
> timezone information when retriving the timestamp information and the
> slightly non-standard interval literal notation (i.e., including the
> year-month or day-time interval information inside the single quotes
> with the literal string).
You will be able to choose "timestamp without time zone" in the next
release.
> My vote on all datetime questions is to stick strictly to the
> standard.
Hmm. It isn't at all clear that the standards guys were awake or sober
when working on the date/time features. I assume that much of the
cruftiness in the standard is forced by influential contributors who
have an existing database product, but maybe there is some other
explanation of why good folks can get so confused.
otoh, I'm not sure why people nowadays would *not* use time zones in
their applications, since everyone is so much more globally aware and
distributed than in decades past.
> Of course sticking to the standard is not always easy as the standard
> is not always clear or even consistent. (I'm only familiar with ANSI
> 92 not ANSI 99.) Time zones in particular seem to be problematic.
:-P
Have you actually used ANSI SQL9x time zones? istm that "one offset fits
all" is really ineffective in supporting real applications, but I'd like
to hear about how other folks use it.
> In this case, I believe that it would be preferable to stick with the
> TIME(0) and TIMESTAMP(6) default precision. In our applications, we
> always specify the precision, so, the default precision is not a real
> concern for us, however, for portability, I still suggest sticking
> with the standard.
We are likely to use the 0/6 convention for the next release (though why
TIME should default to zero decimal places and TIMESTAMP default to
something else makes no sense).
- Thomas