Note: When timestamp values are stored as double precision floating-point numbers (currently the default), the effective limit of precision may be less than 6. timestamp values are stored as seconds before or after midnight 2000-01-01. Microsecond precision is achieved for dates within a few years of 2000-01-01, but the precision degrades for dates further away. When timestamp values are stored as eight-byte integers (a compile-time option), microsecond precision is available over the full range of values.
I think this variance in precision is actually kind of cool - any thought to allowing the "center" of the range to be a build-time option? That is, any particular application might want more precision at a custom center. Does this involve changing more than that one constant?
Hmm, except if the timestamp "anchor" is installation-specific, then binary exchange of timestamps is complicated. What does libpq do now with timetamps, if the client requests data in binary form? How does the client know whether it's getting floats or integers?
- John D. Burger MITRE
