Sign up ×
Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

I'd like to configure some of my notebooks to assume all calculations using dates, times and locations (notably AstronomicalData , but others too) take place at the Greenwich Observatory.

I know I can achieve this by unprotecting $TimeZone and setting it to 0, as with

    $GeoLocation = {51.476786, 0.00000000};
    $TimeZone = 0;

but worry that this might have some other consequences that would confuse date and time functions.

Is it safe to do this? Does changing the value of $TimeZone have side effects I should avoid?

share|improve this question
Can't you put it in a Block? In any case, I don't see any side effects, other than some date conversions and W|A calls getting messed up. – R. M. Dec 4 '12 at 22:35
@rm-rf: Block, if you mean Block[{$TimeZone=0}, ...], wasn't working for me for some functions, at least not DateList]. Also, I'd prefer to make the change global, rather than have to remember to make the change each time I do something that depends on it. – raxacoricofallapatorius Dec 4 '12 at 22:39
Why not use TimeZone? That's what is seems to be for. E.g. Table[DateString[TimeZone -> i], {i, 0, 6}] from the documentation. – David Carraher Dec 4 '12 at 22:43
@DavidCarraher: All calculations, globally. Forgetting to do that just once could really mess things up, and that's what I'm trying to avoid. – raxacoricofallapatorius Dec 4 '12 at 22:46
@rm-rf: Hmmm... Block may not work, simply because DateList looks broken. Try $TimeZone=0 and then DateList[...,TimeZone->0]. That should leave the date given unchanged, but (if you're machine timezone isn't 0) it won't. I may not even be able to do what I want with a global change of $TimeZone. – raxacoricofallapatorius Dec 4 '12 at 22:59

2 Answers 2

$TimeZone is particular to your version of Mathematica, may change, and is not in some versoions of Mathematica.

Do not rely on notebook with $TimeZone hacks working for other Mathematica users.

It's intended to be your time zone for your site for your convenience for "city time" not for sea time, and is not to be a variable time zone used in calculations.

Also someone at WR hacked TimeZone[] to be a different output value. $TimeZone is now documented to be TimeZone[].

I'll have to complian with WR they have a virus injector / incompatibility hacker in their midst.

You should realize your system clock timezone is set somewhat laughably by "local political changes" and has no bearing on good time keeping. (see /usr/share/zoneinfo/localtime or it's rule file for explanation). You can't possibly be "hours west of gmt) that's not accurate. And some localities specifically lie about it for convenience of clock time with a nearby city. Also DST "daylight savings time" changes depending on local laws. Then also George Bush administration hacked in federal changes "a different DST rule for power saving" which is variously followed in any given PC.

13) my TimeZone[] (or \$TimeZone) is ALWAYS ZERO (hours west of grenwich) despite libc time (minutes west of gmt), linux kernel time, and hardware clock time. (note: in mm 9,10 this is now $TimeZone, see (14). There are two reasons to follow.

a) Mathematica (version 4 likely other) at startup checks many "hard coded paths" but never checks the correct INSTALLED libc system path. When glibc installed the --prefix and --exec-prefix options give a base directory where to install libc WHICH IS NOT necessarily "/". libc uses it and programs are "supposed to" check where. One can use strace(1) to verify this error and knowig this the fix is easy: soft link it using ln -s. Here are the paths checked:

/usr/lib/zoneinfo/localtime /usr/share/zoneinfo/localtime /usr/lib/zoneinfo/GMT /usr/share/zoneinfo/GMT /usr/lib/zoneinfo/GMT /usr/share/zoneinfo/GMT

b) GNU/Linux compiled from scratch does not have /usr/share/zoneinfo/localtime. Also /etc/localtime might be /prefix/etc/localtime if libc was installed to /prefix/. Create a softlink in /usr/share/zoneinfo/ such as "ln -s America/New_York localtime". On Debian maybe RedHat the link may have been made (though is also in /etc/localtime so be careful). But on GNU/Linux such an animal is not part of the default system.

14) newer Mathematica so that TimeZone[] is a pretty string and $TimeZone is what used to be TimeZone[]. This means one of the greatest by-laws of Wolfram's promises, that users can share notebooks, is broken.

a new function named TimeZoneString[] could easily have been used so that users could still share NoteBooks using TimeZone[]

I hate to beat a worn out drum but this also is important.

glibc (libc: a ar(1) of functions printf, time, etc) has no timezone per say.

libc always gets time from hardware clock somewhat guessing on which kind (unless proffesionally modified)

GLIBC DOCUMENATION: Software is NOT SUPPOSED TO rely on time(1) giving the correct local time, timezone, epoch, and etc. As glibc documents: software is responsible for checking various things like clock, zoneinfo, user settings, using libc functions to use and format the right localtime, and displaying a resulting correct (or intended) string format.

GLIBC DOCUMENATION: the system time is not necessarily what is shown to the user. it should be checked and or modified using libc functions. A good exmaple is whether user chooses to obey DST, wants to see UTC, or uses military string format or not, if zoneinfo rules for a locality are in effect, and so on. so when Gnome shows you time: it is not necessarily what date(1) or time(2) yields. it's not supposed to be.

share|improve this answer
Hello and welcome. Could you give some examples of the incompatibility you describe? Also if you know exactly in which version something changed we may want to add it to this list. – Mr.Wizard Jun 27 at 14:03

As the Locale & Internalization guide page says $TimeZone is resettable.

Mathematica graphics

If the developers would foresee adverse effects I guess they wouldn't have documented it in this way. The only problem that I can see is that you have to take care that your system time is also set to GMT, otherwise real-time calculations (e.g., elevation of the sun as seen in Greenwich at the time of evaluation) will give the incorrect result.

share|improve this answer

Your Answer


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.