|Maintainer||Leon P Smith <email@example.com>|
Time types that supports positive and negative infinity. Also includes new time parsers and printers with better performance than GHC's time package.
The parsers only understand the specific variant of ISO 8601 that
PostgreSQL emits, and the printers attempt to duplicate this syntax.
datestyle parameter for the connection must be set to
These parsers and printers likely have problems and shortcomings. Some that I know of:
TimestampTZs before a timezone-dependent point in time cannot be
parsed, because the parsers can only handle timezone offsets of a
integer number of minutes. However, PostgreSQL will include seconds
in the offset, depending on the historical time standards for the city
identifying the time zone.
This boundary point often marks an event of some interest. In the US
1883-Nov-18 12:00:00 local time
cannot be parsed. This is the moment Standard Railway Time went live.
Concretely, PostgreSQL will emit
1883-11-18 11:59:59-05 when the
for the connection is set to
- Dates and times surrounding
1582-Feb-24, the date the Gregorian Calendar was introduced, should be investigated for conversion errors.
- Points in time Before Christ are not also not supported. For example,
PostgreSQL will emit
0045-01-01 BCfor a value of a
datetype. This is the year that the Julian Calendar was adopted.
However, it should be noted that the old parsers also had issues 1 and 3. Also, the new parsers now correctly handle time zones that include minutes in their offset. Most notably, this includes all of India and parts of Canada and Australia.
PostgreSQL uses the zoneinfo database for its time zone information. You can read more about PostgreSQL's date and time types at http://www.postgresql.org/docs/9.1/static/datatype-datetime.html, and zoneinfo at http://en.wikipedia.org/wiki/Tz_database.
|Eq a => Eq (Unbounded a)|
|Ord a => Ord (Unbounded a)|
|Read a => Read (Unbounded a)|
|Show a => Show (Unbounded a)|