[plug] Database time fields and DST

[Adrian Chadd]

On Sun, Mar 25, 2007, Bernd Felsche wrote:

> But it's useful to keep the "user" timezone in the record
> especially if access is possible from more than one location.
> You should then always be able to reconstruct the user's wall-clock
> time should the need arise; without delving through external log
> files.

Good suggestion too! Just don't make that a "DST bit".

Avoid having to convert local-timestamps in SQL back to UTC to then
convert back out to whatever the viewing users sees (if there's a need
to display timestamps in the timezone the viewing user is in.) Thats
where a lot of time-manipulation mistakes are made.

(And whilst I'm at it: be careful with time addition/subtraction;
its easy to do it in UTC time but hard to do it "right" across the DST
changes. Another reason to store times in UTC and give thought
to actual DST implications. +2 hours at the wrong time over the daylight
savings changeover can screw billing very subtly and badly.)

(Or, what one company I worked for did (before I got there): just give
people "free" minutes over the two DST changes in the "billing timezone";
which was always Sydney time. :)




Adrian