[tz] tzcode test suite
scs at eskimo.com
Sat Jan 16 13:02:32 UTC 2016
Replies to additional points in three of Paul's messages:
> It should be easier to do the tests with "make tests". Users shouldn't
> need to modify the makefile;
I agree; I'm just not sure how to.
> it should automatically do the 64-bit tests on all platforms,
> making sure that they do the right thing on 32-bit hosts.
(Is "the right thing" to just ignore them?)
> testsuite.c assumes time_t is equivalent to long, by using the %ld
> printf format to print it. That's not portable. time_t might have a
> different width from long, and time_t might be unsigned. zdump.c's
> tformat function gets it right.
That was indeed a bit of carelessness on my part, that I needed
to clean up. I'll take a look at zdump's technique.
>> I think later I discovered
>> it was because I wasn't actually hitting *any* zoneinfo files,
(I am making progress on better error reporting for missing
zoneinfo files; more on that later.)
> Bingo. After doing a 'make install', 'make tests' seems to work. People
> should be able to run tests without installing, though; indeed that
> should be the expected and default way to test.
Again I agree but am not sure how to arrange it. The issue is
that tzcode and tzdata are separate packages; I'm not sure what
the expectation is about how and where people will download them
with respect to each other. And what if someone downloads and
tries to build tzcode without tzdata at all? Perhaps tzcode
would have to contain its own miniature, stripped-down subset of
tzdata, just for testing.
> I'm not sure what that warning about "no nontrivial tz offset tested"
> means, but I hope we can fix the testsuite to set TZ itself if that's
> what it needs to do.
Setting TZ is what I needed to do, although I'm quite surprised
that you had the same problem, so this will bear further investigation.
My issue (under MacOS) is that although TZ is not set when I log
in, the libc versions of localtime() et al. somehow do know what
zone I'm in. But tzcode's localtime.c does not. I assumed Apple
had tweaked tzset() to fetch the default zone from their own
special place. But I think you said you're on Fedora, so where's
it storing its default zone, that tzdata's tzset() can't find?
> The tests took 38 seconds on my 6-year-old work desktop,
Not bad. I tuned them to take a minute on my several-year-old MacBook.
> which is a tad slow for my taste, but we can move the expensive
> tests to 'make check-expensive' or perhaps speed up the library...
In fact I have a 3x speedup waiting in the wings, which I was
waiting to post until the dust died down from this thread. :-)
More information about the tz