(For my debian system at least) there is a file /etc/timezone which contains the timezone in ascii. And /etc/localtime is the current timezone file copied from /usr/share/zoneinfo, containing the timezone Als Europe/Amsterdam.
Exactly the data we need. Does this mean your system looks like this:
pike
Pike v7.6 release 6 running Hilfe v3.5 (Incremental Pike Frontend)
Stdio.read_file("/etc/localtime");
(1) Result: "Europe/Amsterdam\n"
Nope, /etc/localtime is a binary copied from /usr/share/zoneinfo.
/etc/timezone contains the very line: Pike v7.7 release 11 running Hilfe v3.5 (Incremental Pike Frontend)
Stdio.read_file("/etc/timezone");
(1) Result: "Europe/Amsterdam\n"
Is this the wrong way around?
/Marc
On Sat, Feb 26, 2005 at 04:40:01PM +0100, Johan Sundström (Achtung Liebe!) @ Pike (-) developers forum wrote:
(For my debian system at least) there is a file /etc/timezone which contains the timezone in ascii. And /etc/localtime is the current timezone file copied from /usr/share/zoneinfo, containing the timezone Als Europe/Amsterdam.
Exactly the data we need. Does this mean your system looks like this:
pike
Pike v7.6 release 6 running Hilfe v3.5 (Incremental Pike Frontend)
Stdio.read_file("/etc/localtime");
(1) Result: "Europe/Amsterdam\n"
Is this the wrong way around?
No, but I did an embarrasing cut'n'paste:o. :-) Anyway, I thought the Calendar module's localtime timezone guessing system could be made to look for this to improve its guessing. Closer looking at TZnames.pmod makes me guess it might be the wrong approach, though -- the mapping timezone_expert_tree does have an entry for Europe/Amsterdam, but for some reason it doesn't seem to help. This nearby comment:
// note that at least Red Hat 6.2 has an error in the time database, // so a lot of Europeean (Paris, Brussels) times get to be Luxembourg
suggests it could be worth testing whether Debian is showing similar bugs or if the expert tree needs improvements.
suggests it could be worth testing whether Debian is showing similar bugs or if the expert tree needs improvements.
I'm not sure how things exactly should work, as Mirar explained, the export of TZ in the environment does the trick. It might be enough to mention this somewhere in the documents for system that fail.
But what is the overall standard for this? Not just linux? Since having several tests to match every different system is not actually speeding up the code. Although it might be made to check the TZ export, and if that fails fall back to more thorough testing. Although the TZnames.pmod is rather complex, if I use date for example:
$ date +%z +0100 $ date +%Z CET
Isn't this usefull, I don't need it actually to fall back to Europe/Amsterdam, just not using Timezone.localtime() and use the correct offset (+0100) is enough.
/Marc
$ date +%z +0100 $ date +%Z CET
Isn't this usefull, I don't need it actually to fall back to Europe/Amsterdam
It unfortunately isn't (for telling if and when the DST shift is), and the Calendar module needs to know that.
If you only use the Calendar module to do very basic operations that time(), localtime(), gmtime() and mktime() could easily do instead, you may want to sacrifice the convenience of the more complex Calendar engine and save some execution time. For cases where you are likely to need better range than the syscalls allow, or do nontrivial time math, Calendar is still probably your best option, though.
(Of course this is not just a matter of execution time tradeoffs; the development time you save on not reinventing needless low-level time treatment bugs by using the library can be substantial.)
pike-devel@lists.lysator.liu.se
-
Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum -
Marc Dirix