FW: timezone question
Paul Eggert
eggert at twinsun.com
Mon Jul 19 21:00:58 UTC 1999
From: Durk Talsma [SMTP:d.talsma at direct.a2000.nl]
Sent: Friday, July 16, 1999 11:09 AM
I also found out that by faking a TZ environment variable, I'm capable
of retrieving the right local time on my linux box. However, one of our
goals is portability, and I don't know whether this trick will also work
on other platforms, such as Windows or the Mac, using their native
localtime() functions.
You might try looking at the latest version of GNU Emacs to see what it does:
http://www.gnu.org/software/emacs/
Emacs needs to address this issue, and it has Mac and Windows ports.
See the function set_time_zone_rule in src/editfns.c.
You might also look at the Windows port for XTide. XTide does a lot
of localtime manipulation. See:
http://www.flaterco.com/xtide/files.html
I consider redistributing your timezone definition files with
flightgear, along with a modified version of the glibc's
localtime() function. For this reason, I have two questions.
First, do you think it is necessary to do this, or is there a relatively
simple way to get this information from the native OS'ses?
David Flater, the XTide maintainer, has reported a lot of problems
dealing with localtime bugs (and the localtime interface) on various
POSIX OSes, so it might well simplify matters for you and your users
if you would distribute the timezone definition files and subroutine
as part of flightgear. I would suggest making it a configuration-time
option, e.g. `configure --with-included-localtime' or something like
that.
And second, are we allowed to use your timezone information files,
or code, and redistribute them with our project?
Yes. Those files and code are public domain, and are regularly
distributed as part of both free and non-free software packages.
under linux, this stuff becomes pretty simple:
1. set up a fake environment var e.g. (pseudo code)
char ** fake = { "europe/Amsterdam", 0};
environ = fake;
(I assume you mean "TZ=Europe/Amsterdam" instead of "europe/Amsterdam".)
I think it'd be better to append the previous environ to the new
variable-value pair, since some implementations access other
environment variables. E.g. glibc accesses TZDIR as well as TZ.
More information about the tz
mailing list