On 12/01/17 14:09, Tim Ward tdw@... [firebird-support] wrote:

> Can someone point me in the right direction please?

There have been many attempts to justify storing a time stamp complete
with timezone directly in a time field, but the real answer is that it
is always wrong. Store location data in addition to a UTC time stamp and
that way you can always display a correct time, and more importantly
correctly move a time when passing over a DST change. The one thing that
is missing from the 'offset' supplied by a browser is any means of
identifying if the offset will be the same next month. You need to know
the correct time zone and not just the current offset which is why a
time with an offset may be wrong half of the year.

Another piece of the jigsaw is the problem of identifying what the
current offset data is in relation to a timezone. If you have created a
UTC normalized time and have a timezone which gives you an offset, then
the DST rules change, you will only know of the change if you have
recorded the version of the rule set you normalised the time with, and
the current rule set. So timezone/version is the additional data that
should be recorded once working with UTC normalized times.

And if you are running a system supporting several time zones then the
server clock should always be set to UTC time. Trying to calculate UTC
then Local time from a server time that may also have DST variations
creates no end3of edge cases :) Store all times as UTC unless you are
ONLY working with one timezone, but even that is tricky if your time
zone uses DST ...

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk