I'm thinking about getting around to integrating Pike with the tzdata package in Debian, which I was talking about at the conference some years ago, but I need to check and understand some things first.
If I understand correctly, the Calendar module knows about daylight savings time and other jumps in local time in different regions, which is has to in order to convert past moments in time between local and universal time, but it doesn't make use of the operating system for this (except to find out what the current local timezone is), only data provided with the source code (which as of 8.0.182 is from 2013).
Now, there is mkrules.pike, which compiles the tzdata files into a set of classes, but it apparently isn't run at build time and while I guess that one could use the generated classes directly, I can't see that they are used by Calendar.Timezone. The following comment suggests that mkrules.pike was discontinued but left in the source tree.
// ================================================================ // this is to runtime-compile timezones // it's not very nice; based on the one-time-compilation // utility I wrote first - but that method was too slow :/ // ================================================================
Now, having the tzdata source package create a tzdata-pike package by running mkrules.pike would have created a bootstrapping problem as pike8.0-core would depend on a package that itself would be needed for to build, so perhaps it's only easier to create a package that simply installs the tzdata source files in the right location?
I'm thinking about getting around to integrating Pike with the tzdata package in Debian, which I was talking about at the conference some years ago, but I need to check and understand some things first.
If I understand correctly, the Calendar module knows about daylight savings time and other jumps in local time in different regions, which is has to in order to convert past moments in time between local and universal time, but it doesn't make use of the operating system for this (except to find out what the current local timezone is), only data provided with the source code (which as of 8.0.182 is from 2013).
2013?? As far as I know, Pike 8.0.182 should come with tzdata2016a.
Now, there is mkrules.pike, which compiles the tzdata files into a set of classes, but it apparently isn't run at build time and while I guess that one could use the generated classes directly, I can't see that they are used by Calendar.Timezone. The following comment suggests that mkrules.pike was discontinued but left in the source tree.
mkrules.pike should be run each time the tzdata files are updated.
// ================================================================ // this is to runtime-compile timezones // it's not very nice; based on the one-time-compilation // utility I wrote first - but that method was too slow :/ // ================================================================
Hmm... That comment is AFAIK incorrect.
Now, having the tzdata source package create a tzdata-pike package by running mkrules.pike would have created a bootstrapping problem as pike8.0-core would depend on a package that itself would be needed for to build, so perhaps it's only easier to create a package that simply installs the tzdata source files in the right location?
You could have the tzdata-pike package not depend on pike, and just have it being a noop it if pike isn't installed.
If I understand correctly, the Calendar module knows about daylight savings time and other jumps in local time in different regions, which is has to in order to convert past moments in time between local and universal time, but it doesn't make use of the operating system for this (except to find out what the current local timezone is), only data provided with the source code (which as of 8.0.182 is from 2013).
2013?? As far as I know, Pike 8.0.182 should come with tzdata2016a.
OK, I may have made a hasty conclusion based on a date in the africa file.
Now, there is mkrules.pike, which compiles the tzdata files into a set of classes, but it apparently isn't run at build time and while I guess that one could use the generated classes directly, I can't see that they are used by Calendar.Timezone. The following comment suggests that mkrules.pike was discontinued but left in the source tree.
mkrules.pike should be run each time the tzdata files are updated.
Who's responsible? There's nothing in the source tree that runs it, neither in the makefiles nor in the packaging directory, and it's not mentioned in any documentation or FAQ. And the question remains: how are the generated files used?
// ================================================================ // this is to runtime-compile timezones // it's not very nice; based on the one-time-compilation // utility I wrote first - but that method was too slow :/ // ================================================================
Hmm... That comment is AFAIK incorrect.
Now, having the tzdata source package create a tzdata-pike package by running mkrules.pike would have created a bootstrapping problem as pike8.0-core would depend on a package that itself would be needed for to build, so perhaps it's only easier to create a package that simply installs the tzdata source files in the right location?
You could have the tzdata-pike package not depend on pike, and just have it being a noop it if pike isn't installed.
The tzdata source package would have to Build-Depend on pike8.0-core so that it can create a binary package with the compiled timezone rules. But if the tzdata sources are still needed by Pike, one could as well package them and compile them at install time.
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum