On Jul 16, 2004, at 1:55 PM, Tom Lane wrote:
This is in fact wrong, unless you live in the British Isles: the result will be off by your timezone displacement from UTC. Correct is to use timestamptz not timestamp.
Thanks. Timestamps and time zones are a challenge for me.
A cast from integer is probably a bad idea, seeing that it will break in
2038. You could make an argument for a cast from double though. The
issue to my mind is whether this might be too Unix-centric.
In my mind, epoch is pretty Unix-centric. In IRC we often see people who want to store timestamps in their db as strings or integers, which we are sure to point out isn't necessarily the best way to take advantage of PostgreSQL's strengths in handling timestamps.
Having these (corrected) functions available would be enough in my mind. The casting idea came about when I was thinking about where I'd put the functions in the documentation.
Michael Glaesemann grzm myrealbox com
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
