Be sure direct replies to Durk, who's not on the time zone mailing list. --ado -----Original Message----- From: Durk Talsma [SMTP:d.talsma@direct.a2000.nl] Sent: Friday, July 16, 1999 11:09 AM To: tz@elsie.nci.nih.gov Subject: timezone question Hello, First of all, please let me introduce myself, my name is Durk Talsma, and I am currently helping in developing a GPL'ed Open Source Flightsimulator (http://www.flightgear.org). One of the things I'm currently working on is getting the local time right for any given location of an aircraft. Using your tzcode and tzdata packages, I started experimenting, and currently I am able to select the nearest timezone relative to an aircraft's position. 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. So for this reason, 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? And second, are we allowed to use your timezone information files, or code, and redistribute them with our project? By the way, the email adres I'm posting to right now was the only adress I could find for contacting you. Currently, I don't know who I'm sending this to, and I also don't know whether I'm sending this message to a private mail adress or a mailinglist. I also hope that my questions are appropriate to send to this adress. I've attached my latest message to the flightgear developers mailinglist below, to explain a little further what I'm working on. Thanks for reading. Best regards, Durk Talsma Hi, In part, this message is to give a small update on my timezone parsing code, and in part it is also intended to get some advice. First of all, it looks like I made good progress on the timezone parsing code. Currently, I'm able to parse the timezone database, and select the nearest timezone, based on the angle between my current location and the location of the timezone centerpoints, as described in the zone.tab file (thanks Norman!). Currently, I'm only using a spherical world model, but since I've written a little class to store geographical coordinates, this should be pretty easy to convert to something a little more complex. As for retaining the current local time, my original intention was to write some code of my own to parse the timezone values, but just before doing so, I found out that these functions are part of glibc already. So, after hacking around a little, I found out that localtime is determined through an environment var, that points to a file containing timezone info. So 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; 2. Get the time getlocaltime(); 3. Restore environ = oldEnviron; // point the environment to its origninal location I'm also pretty convinced that this won't work under other platforms, as those have a different mechanism for retrieving timezone info. So my idea would be to adapt the glibc code for use in flightgear, and also making the timezone informationfiles part of the fgfsbase package. After all, this is pretty close to my original idea of writing my own tz parser. This would save me quite some time. On the other hand, and this is my question: if somebody has a better idea, than I'd be very interested. Regards, Durk -- ----------------------------------------------------------------------- You can contact me at: pn_talsma@macmail.psy.uva.nl (work) talsma@uvapsy.psy.uva.nl (more work) d.talsma@direct.a2000.nl (home at last) Or visit my website at: http://people.a2000.nl/dtals ---------------------------------------------------------------------- "Dave, this conversation can serve no further purpose anymore, goodbye" - HAL 9000 - -- Please visit the FGFS web page: http://www.flightgear.org For help on using this list (especially unsubscribing), send a message to "fgfs-devel-request@flightgear.org" with a single line of text: "help".
From: Durk Talsma [SMTP:d.talsma@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.
participants (2)
-
Olson, Arthur David (NCI)
-
Paul Eggert