10
$\begingroup$

My reading of the documentation for DateList and DateString lead me to believe that both functions use $TimeZone to determine the time zone to use in interpreting their inputs. Thus, for example, if the local machine time zone is UTC-5, $TimeZone is -5, and the time at Greenwich, corresponding to a given time in the local time zone can be found by specifying TimeZone -> 0 as an option:

DateList[{2012, 10, 8, 7}, TimeZone -> 0]
{2012, 10, 8, 12, 0, 0.}

DateString[{2012, 10, 8, 7}, TimeZone -> 0]
"Mon 8 Oct 2012 12:00:00"

To base these calculations off a different time zone, one should simply have to change the value of $TimeZone, either temporarily, using Block, or globally, by unprotecting and changing $TimeZone. But neither of these approaches works as expected. Both behave as if the machine's time zone, and not $TimeZone is being used to determine the local time zone:

Block[{$TimeZone = 0}, DateList[{2012, 10, 8, 7}, TimeZone -> 0]]
{2012, 10, 8, 12, 0, 0.}

Block[{$TimeZone = 0}, DateString[{2012, 10, 8, 7}, TimeZone -> 0]]
"Mon 8 Oct 2012 12:00:00"

(* Machine time zone is UTC-5 throughout; $TimeZone = 0 until changed below *)
Unprotect[$TimeZone]; $TimeZone = 0;

DateList[{2012, 10, 8, 7}, TimeZone -> 0]
{2012, 10, 8, 12, 0, 0.}

DateString[{2012, 10, 8, 7}, TimeZone -> 0]
"Mon 8 Oct 2012 12:00:00"

And even weirder:

DateList[{2012, 10, 8, 7}]
{2012, 10, 8, 7, 0, 0.}

DateList[{2012, 10, 8, 7}, TimeZone -> $TimeZone]
{2012, 10, 8, 12, 0, 0.}

And yet more timey-wimey:

AstronomicalData["Sun", {"RightAscension", {2012, 10, 8, 7}}]
12.958492

AstronomicalData["Sun", {"RightAscension", {2012, 10, 8, 7}}, TimeZone -> 0]
12.958492

AstronomicalData["Sun", {"RightAscension", {2012, 10, 8, 7}}, TimeZone -> $TimeZone]
12.958492

which all seems okay until1

Unprotect[$TimeZone]; $TimeZone = -5

AstronomicalData["Sun", {"RightAscension", {2012, 10, 8, 7}}]
12.958492

AstronomicalData["Sun", {"RightAscension", {2012, 10, 8, 7}}, TimeZone -> 0]
12.945765

AstronomicalData["Sun", {"RightAscension", {2012, 10, 8, 7}}, TimeZone -> $TimeZone]
12.958492

The second set of AstronomicalData calculations (with $TimeZone = -5, the machine time zone) is at least consistent with what DateList and DateString seem to be doing: input is interpreted as being in the machine time zone (regardless of $TimeZone), unless a different time zone is specified using TimeZone. But that seems to be precisely the problem: if the time zone specified with TimeZone matches $TimeZone, it's ignored, even if the machine time zone is different. So in the first set of AstronomicalData calculations (with $TimeZone = 0), when TimeZone is '0' or $TimeZone, the option is just ignored, and AstronomicalData reports data for the default, machine time zone instead.

If $TimeZone is merely the default setting for TimeZone options and not the default time zones for executing time zone dependent functions, how do I get date and time functions to work in another time zone by default (without changing the machine's clock)?


1. I know the Sun's RA isn't the best value to use to spot differences over hour time scales, but since I can't get a straight answer from Wolfram (after 2 weeks of trying) about whether Mathematica ephemerides incorporate parallax or atmospheric effects, I wanted to be sure I had used something that would be immune to those effects when viewed from two different locations, since I don't specify those in the example.

$\endgroup$

1 Answer 1

1
$\begingroup$

You are not using the functions correctly

In[9]:= DateString[]
Out[9]= "Tue 30 Apr 2013 09:37:20"

while

In[10]:= DateString[TimeZone -> 0]
Out[10]= "Tue 30 Apr 2013 07:37:26"

and

In[33]:= AstronomicalData["Sun", {"NextRiseTime", {2012, 10, 8, 6, 0, 
   0}}, TimeZone -> 1]
Out[33]= {2012, 10, 8, 6, 35, 31.7528}

In[34]:= AstronomicalData["Sun", {"NextRiseTime", {2012, 10, 8, 6, 0, 
   0}}, TimeZone -> 4]
Out[34]= {2012, 10, 8, 9, 35, 31.722}

work as expected.

$\endgroup$
1
  • $\begingroup$ Can you explain how you think this addresses the question? $\endgroup$
    – orome
    Jan 9, 2014 at 14:28

Your Answer

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

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