# TimeZone Anomaly

I ran into the following situation when I was trying to determine the time of sunrise (using the built-in Sunrise function) for a variable location on a variable day:

In order to get the time of sunrise, I need to specify the date of interest (at that location) i.e. a DateObject needs to be constructed using the LocalTimeZone for the location. I can easily enough get the timezone using the LocalTimeZone built-in function for the location of interest. However, the call to LocalTimeZone requires a date, because the "timezone" (really time offset from GMT) can change due to Daylight Saving Time ("summer time").

Hence, the date depends on the timezone that depends on the date--a circular definition. At some point a specific value must be used, which will likely take advantage of a default (e.g. today or the current location), which might not be correct for the actual situation.

BTW: I found this site that provides 380.4 kb of code and data for covering the Earth for just 2016, indicating the complexity of the problem.

Here is some code showing how the data about Atlanta (where I am) creeps into the calculation.

sydney = Entity["City", {"Sydney", "NewSouthWales", "Australia"}];
tz = LocalTimeZone[sydney];    (* Today!!! *)
date = DateObject[{2016, 12, 22, 1, 1}, TimeZone -> tz];
Sunrise[sydney, date, TimeZone -> tz]


My question is: is my analysis correct, and if so, is there a workaround?

(I am running Mathematica v10.2.)

## 1 Answer

Sydney does observe DST, so one should see a jump in the local sunrise time when they switch. To get the local sunrise time, I would use:

LocalTime[loc, Sunrise[loc, date]]


For example:

city = Entity["City", {"Sydney", "NewSouthWales", "Australia"}];

In[149]:= Map[
LocalTime[city,#]&,
Sunrise[
city,
DateRange[DateObject[{2016,9,30}, TimeZone->LocalTimeZone[city]],DateObject[{2016,10,4}]]
]["Values"]
] //InputForm

Out[149]//InputForm=
{DateObject[{2016, 9, 30}, TimeObject[{5, 35}, TimeZone -> 10.], TimeZone -> 10.],
DateObject[{2016, 10, 1}, TimeObject[{5, 34}, TimeZone -> 10.], TimeZone -> 10.],
DateObject[{2016, 10, 2}, TimeObject[{5, 32}, TimeZone -> 10.], TimeZone -> 10.],
DateObject[{2016, 10, 3}, TimeObject[{6, 31}, TimeZone -> 11.], TimeZone -> 11.],
DateObject[{2016, 10, 4}, TimeObject[{6, 29}, TimeZone -> 11.], TimeZone -> 11.]}


One can clearly see that DST ended on Oct 2.

• Thanks for the suggestion, but, unless I am mistaken, the call to LocalTimeZone uses today's date to determine the value of the timezone and not the date of the Sunrise in question. If they are different, then I can see a problem arising. This circular dependency is the problem I am trying to overcome. – Spencer Rugaber Jan 3 '17 at 16:28
• The call to LocalTimeZone is just to make sure that the sunrise is computed on the correct day. That is, DateObject[{2016, 9, 30}] without the time zone specification here in California is equivalent to 11AM in Sydney, and so the sunrise you will get is for October 1, not September 30. Adding in the local time zone makes sure that the sunrise will be computed for that day, and being off by 1 hour because of DST won't change which day the sunrise is computed for. – Carl Woll Jan 3 '17 at 17:46
• I still see a problem: The call to LocalTimeZone specifies the offset from GMT today, not the date in question. This offset may change if DST begins on different dates in Greenwich and Sydney. I can't see a way out of the problem without relying on some time standard that doesn't depend on a geographical location. – Spencer Rugaber Feb 3 '17 at 12:57
• @Spencer Rugsber You should provide an example. – Carl Woll Feb 3 '17 at 15:36