Bart Smaalders wrote:
> Darren J Moffat wrote:
>> Bart Smaalders wrote:
>>> Changing the system time is just wrong; we need a way to
>>> have a "rubber" timezone then.  I want logs, etc, to
>>> remain ordered in the "systems" view of time; having
>>> /var/log/* files out of order because we're monkeying with
>>> the system clock to get the desktop time right is backwards.
>>>
>>> If we can handle daylight savings time, we can have a traveling
>>> time zone for desktops.
>>
>> Agreed but we need it to be possible without requiring a logout/login 
>> event.
>>
> 
> After talking to our standards guru, it appears that
> the behavior of timezones beginning w/ something other than
> a letter or a : is undefined.  It appears possible to grab
> some punctuation (say a leading '/' :-)) and define a new
> behavior for such timezones that causes them to be interpreted
> as a file containing the name of the current timezone.

the security part of me says NOOOOO.  Why ?  this reminds me too
much of the problems we had in the past with libc and NLS files.
specifying paths to things in environment variables can get you
in trouble in very unexpected ways sometimes.

However I think in this case we should be able to do this safely since 
these are pure data files not code files.

> This would allow changing a timezone dynamically by modifying
> the file to contain the name of the newly desired timezone;
> applications would transparently get the new timezone when
> they next called ctime and friends.

Hmn interesting....  and with a little bit of zenity(1) you
could even get a GUI for this :-)


-- 
Darren J Moffat

Reply via email to