Take the 2-minute tour ×
Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

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.

share|improve this question
add comment

1 Answer 1

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.

share|improve this answer
    
Can you explain how you think this addresses the question? –  raxacoricofallapatorius Jan 9 at 14:28
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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