rcdmk
commented
7 years ago Hi. You are completely right.
- One way of dealing with this would to assume that every date provided is in UTC time.
- Another way would be to use the Unix Epoch format, using the number of seconds since Epoch.
Have you any other suggestion? What do you think about the solutions I mentioned above?
Thank you,
The method of getting the timezone offset from the server is flawed. This method is appropriate only if you are looking for the current time.
But for calculating offset for any date/time in the past it will be incorrect if the current system time is within daylight savings time and the time you are calculating occurred outside of DST (or vice versa) In those cases the time would be off by the amount of the difference between DST and ST.
E.g If i am in Eastern timezone in the USA during DST, and calculating the offset of a time in the past that was not in DST... the result will be incorrect by 60 minutes. For Eastern time zone, the UTC offset is -5 (fall winter) and -4 in spring/summer.
Places that use Eastern Standard Time (EST) when observing standard time (autumn/winter) are 5 hours behind Coordinated Universal Time (UTC−05:00). Eastern Daylight Time (EDT), when observing daylight saving time DST (spring/summer) is 4 hours behind Coordinated Universal Time (UTC−04:00).
I've dealt with this a lot in the past and in all cases you need, at minimum, a lookup DST start and end dates each year for which you can use to determine whether the datetime you are working with was within a DST period or not.
w3.org has perhaps a more concise explanation if mine didn't make sense:
https://www.w3.org/TR/timezone/#pastfuture