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 1


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[
        DateRange[DateObject[{2016,9,30}, TimeZone->LocalTimeZone[city]],DateObject[{2016,10,4}]]
] //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.

  • $\begingroup$ 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. $\endgroup$ Jan 3, 2017 at 16:28
  • $\begingroup$ 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. $\endgroup$
    – Carl Woll
    Jan 3, 2017 at 17:46
  • $\begingroup$ 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. $\endgroup$ Feb 3, 2017 at 12:57
  • $\begingroup$ @Spencer Rugsber You should provide an example. $\endgroup$
    – Carl Woll
    Feb 3, 2017 at 15:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.