Hi, I already sent a message of similar contents to Paul Eggert. If he had already forwarded that to this list, please accept my apologies for the repetition. On Thu, May 06, 1999 at 02:32:45PM -0700, Guy Harris wrote:
Unfortunately, the optimal solution is to load the rules from a file, which we already do, but that doesn't work if the database is uninstalled.
My inclination is to say "the optimal solution depends on the database being installed; if we can't even find 'posixrules', use some possibly-wrong hardcoded rules".
In the meantime I have changed my mind about the subject and I actually disagree with such a solution: These possibly-wrong hardcoded rules will most probably be rules which may produce acceptable results for only the northern hemisphere. For the southern hemisphere they will be totally wrong, the difference will typically be two hours and that error will appear for most of the year. I would prefer to entirely ignore DST for this case and set the variables that indicate that DST is in use during some part of the year to -1 (undecided). Such an assumption will probably produce better results. An alternative would be to extract the rules and zone names for today (not the past or future) from the source files and hardcode them into the library. It would then be possible to calculate rules which cover the entire range of time_t values at run-time as long as a known zone name is used. Unfortunately, this solution would probably be faster than reading a database file and the results would still be acceptable for 99 % of the users. Ciao Guido -- http://stud.uni-sb.de/~gufl0000 mailto:gufl0000@stud.uni-sb.de