On 12/01/17 14:09, Tim Ward t...@telensa.com [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
