Because it requires that the string "Zone Europe/Belfast" exists in the timezone data, which it doesn't (Belfast is a "Link", not a "Zone"). The search() code only require that the string "Europe/Belfast", without "Zone", exists.
If the format of the tzdata files sucks for parsing, a make rule to dump them in some O(1) lookup friendly format might be an improvement?
Per has already proven that they don't suck for parsing, and that reading it all in at once is faster, afaik?
I meant something like an encode_value'd mapping read on first need, but if there is code which both works and is speedy, I'm not one to argue. :-)
Speaking of tzdata, those files have been updated several times over the years, yet the expert tree at the end of TZnames.pmod is still from 2000. Shouldn't they be kept in synch?
Yes, they should. Fortunately, all the usage there is historical and not prone to change much...
I seem to have lost the generator, too.
It should probably be removed from TZnames if it's not a zone, but it's a good find anyway. Does
Regexp.PCRE.Studied re=Regexp.PCRE.Studied("([Ll]ink|[Zz]one)[ \t]*"+s+"[ \t]");
solve that problem, then? I don't seem to have a working Pike at the moment, so I can't try.
I don't think it would; the line is
Link Europe/London Europe/Belfast
and not the other way around...
Ah well,
Regexp.PCRE.Studied re=Regexp.PCRE.Studied("(([Zz]one[ \t]*"+s+"[ \t])|([Ll]ink[ \t]*[^ \t]+[ \t]+"+s+"))");
then? Seems to solve the problem for me (I got one running).
pike-devel@lists.lysator.liu.se
-
Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum