More l_fp=>time_t cleanup

[Hal Murray]

I just pushed fixes for filegen/logging that Gary spotted.

The old code used to use local calendar routines to get things like the 
beginning of the month and the beginning of the next month.  mktime uses the 
local zone.  There is no equivalent that uses UTC.  The current code will go 
through the recalculations each day.  If you are doing monthly log files, 
that will get the same file name.  Just a few extra CPU cycles every now and 
then to keep the code sane.

Is anybody using anything other than daily log files?  I haven't tested the 
other modes.  I implemented the week mode based on the documentation.  It 
might be off by a day from the old code due to starting at 0 or 1.

Is there an approved way to print time_t that works on all systems?  I'm 
currently using %lld and (long long)foo.

I added --enable-debug-timing to one of the batches in tests/option-tester 
and fixed the handful of compile time problems it exposed.  I haven't tried 
running it.




There are many more opportunities.

One batch is in the refclocks.  I haven't investigated.  Eric: If you are in 
the right mood, you might take a look.

There is another small lump in the MRU stuff.  I'll work on that one of these 
days unless somebody beats me to it.

There is a tangle in some of the pretty date formatting area.  Some code 
seems to only be used by python.  There may be duplicates in 
libntp/prettydate.c and ./libntp/humandate.c  In any case, it seems strange 
to have 2 modules for the same sort of stuff.  Maybe there is a clean split 
that I haven't noticed.


-- 
These are my opinions.  I hate spam.