4

I've moved to fluxbox as my default environment on our corporate environment. I obviously can't change the time on the machine. But I'd like the clock to show my local time instead of the machine's local time.

Any way that can be achieved?

Tsvi M
  • 141
  • 3
  • You could try your luck with the `TZ` variable http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html – frostschutz Sep 09 '13 at 11:40

2 Answers2

4

To expand slightly upon @frostschutz comment, the TZ environment variable is present in large part to allow exactly what you desire: having programs show you time information in your preferred zone.

Indeed, Unix system clocks all run on UTC (GMT-like) and things like file timestamps and what your clock program gets back from the system is in UTC. Programs like ls and your clock program usually look to the system default timezone (often stored in /etc/localtime) unless the TZ environment variable is set.

The program tzselect helps you choose the proper time zone and shows you how to change your .profile to set TZ. It doesn't actually make any changes for you.

msw
  • 10,503
  • 1
  • 31
  • 43
  • Note that system clocks don't have to run on UTC, that is just the convention. You can tell the system the hardware clock is using some other timezone, and thus also (for what it's worth) not have to use a software zone translation. – goldilocks Sep 09 '13 at 12:08
  • True. You could also run your system on Martian Time if you were sufficiently perverse, but it would make things… inconvenient. – msw Sep 09 '13 at 12:10
  • Not to recommend or endorse, but that's what I've almost always done with stand-alone systems (well, not martian time, but the real center of the universe, EST) -- eg. my desktop -- and it has never been any source of grief or inconvenience. For remote servers, if it is up to me they're on just plain UTC, so again the system matches the hwclock. – goldilocks Sep 09 '13 at 12:26
  • As long as you get to define every clock that matters, running on Goldilocks Time is no problem at all. UTC is one convention that I'm not willing to violate as it can cause all sorts of human and computer confusion when you (for example) transfer files to a machine outside your control which will have been previously modified in the future. And, as Douglas Adams has pointed out, getting the grammatical tenses right for describing such actions is the really tough part. – msw Sep 09 '13 at 12:36
  • "when you (for example) transfer files to a machine outside your control" ??? The creation time of the file transferred is the time of the transfer to the machine in it's local time because *file meta-information, including timestamps, is not part of the file or the transfer*. Your file transfer software deals with that stuff manually as it wants if it wants. So this problem never happens...but I agree that people might as well stick with the convention. Just pointing out it is not a necessity. – goldilocks Sep 09 '13 at 12:50
  • 1
    I do think we've gotten a tad discursive, but `tar cf motd.tar /etc/motd; scp motd.tar my-machine:/motd.tar` begs to disagree with "never happens". – msw Sep 09 '13 at 13:15
  • Right, because you used tar, which does stash meta-information. Notice if you set the clock on the destination machine off by one hour, the timestamp *on* the tar file would be that time (!= the timestamps *in* the tar), not the time from the sender, because scp is not so dumb: since you can't depend on other machines being unix, or having the right time, using this kind of method (hardcoding stamps a la tar) to sync files on a network would be a *bad choice*. – goldilocks Sep 09 '13 at 13:18
  • So to digress further into discursion (I was your +1, BTW): the Unix convention here may be venerable, but it is also vulnerable to the problems you describe because it assumes all machines on a network will be on the same page clock wise (= *bad assumption*). Notice that, e.g., VCS software like `git` will not depend on timestamps for synchronization or transfer them -- it creates local timestamps appropriate to the time of the transfer and completely unrelated means for synchronization (= *better idea*). – goldilocks Sep 09 '13 at 13:39
  • 1
    My system clock started running backwards after reading this. – frostschutz Sep 09 '13 at 16:31
0

Based on the info provided by @msw and @frostschutz, I added the following line in my ~/.fluxbox/startup file before the line calling exec fluxbox:

export TZ=Asia/Jerusalem

This did the trick, thanks all for your help and fun comments.

Tsvi M
  • 141
  • 3