Four Corners Noise

Tom Whitten's Weblog


20050928 Wednesday September 28, 2005

 Adjusting Solaris Time Zones

The question of time zones is often times framed as a mobility issue. If I hop on a plane in Colorado which is in the US/Mountain time zone and fly to California, I would like my lap top to display US/Pacific time while I'm in California. When I go back home, I want my laptop's times to be back in Mountain time.

I maintain that the time zone issue is more than just a mobility issue, however. When I'm sitting in my Colorado office and login to a machine in California, the California machine displays Pacific time. Wouldn't it be nice if it would show Mountain time for me. In this case neither the machine nor I are changing our locations.

There is a quick and dirty solution to both of these problems. Change the value of the TZ environment variable. The library routines that deal with the display of time check the value of the TZ environment variable and adjust the displayed time accordingly. Give it try on a machine near you. echo TZ and note the current value, so that you can restore it. Now set TZ to a different value and type date. The time is displayed according to the TZ environment variable. I use this trick when I login to machines in California.

The default value for TZ is established in /etc/default/init for a given machine. As we have seen, an individual can override the value of TZ. A crude tool for changing time zones could be provided. When the user invokes the tool, it could edit the .profile or .chsrc to set TZ to the desired time zone. There are a number of major disadvantages to this, however:

  • It is not nice to edit a users .profile or .chsrc.
  • It is difficult to automatically determine how to edit these files to accomplish the desired effect.
  • Processes that are already running would not see the new TZ, so the user would need to logout and login again.

I propose a different mechanism that requires more work. Instead of modifying .profile, the tool should place the user's desired time zone in a user specific repository. For this discussion, I do not want to dwell on the mechanism of a user specific reprository. It could be a dot file in the user's home directory, or it could be something more fancy. Next we need to modify the libraries that deal with the display of time, and find all the routines that interrogate the value of the TZ environment variable. These routines should be changed to first look for the time zone specification in the user specific repository. If this check fails, then look at the TZ environment variable. Changing the libraries in this way, means that running processes will see the change and begin displaying the time in the new time zone.

Here are features of this approach that are appealing to me:

  • The realtime clock is not changed. See Casper Dik's blog on the problems of chaning the RTC in a multiboot environment.
  • A corollary to the previous item is that the RTC clock can be set for UTC (GMT) time. This is what Unix has done from its inception.
  • The solution is user specific, rather than machine wide. Thus, on a multi-user system (this is Solaris after all), each user can see the time in the zone of her or his choice.


( Oct 05 2005, 09:10:24 AM MDT / Sep 28 2005, 03:11:20 PM MDT ) Permalink Comments [1]
Trackback: http://blogs.sun.com/4ctom/entry/adjusting_solaris_time_zones

Comments:

Interesting questions!

I'm not sure that I know what the correct answer to the timezone question is. As a user, I think that it's natural to use my personal timezone, but as an administrator the machine's timezone (which is what determines what gets into the various log files) is more appropriate. I know it's confusing - I've been confused more than once.

But why stop at the timezone? What about locale, or printers, or any other settable parameter?

In fact, why not extend the framework to support any environment variable? This has massive advantages: no more editing 20,000 user .cshrc files for one. Plus the ability to have an API for managing settings, and the elimination of users mangling their setting by misguided edits to dot files.

(One thing that was never good and is getting worse is the whole area of user preferences or settings. Inheriting all environment variables doesn't scale; I've already got several hundred dot files; and the current desktop environments have their own schemes. It's a horrid mess. Why not try to solve the whole problem in one go?)

I think you have the ordering backwards. The primary source should be the environment, with the repository check only being done if that fails to return an answer. This preserves the expected semantics of the environment, and also makes sure that users and repository-unaware applications can trivially set whatever values they like for the current process. It would mean that certain environment variables that are traditionally set (like TZ) would have to be unset by default, so that they are pulled from the repository.

This then leads to a trivial (if not necessarily efficient) implementation. Simple replace getenv() with a version that looks for a variable in the environment in the traditional way, and then tries the repository as a fallback.

Another question is raised by your discussion - is the environment of a process stable over time, or could it change while the application is running? You seem to assume that changing the environment of a process is desirable, but I would expect that few applications would be prepared to cope.

Posted by Peter Tribble on October 09, 2005 at 03:06 PM MDT #

Post a Comment:

Comments are closed for this entry.

« November 2009
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
     
       
Today


XML







Today's Page Hits: 0