FW: time zone library

[Robert Elz]

    Date:        Mon, 12 Jan 2009 17:38:48 -0500
    From:        "John Dlugosz" <JDlugosz at TradeStation.com>
    Message-ID:  <450196A1AAAE4B42A00A8B27A59278E70925C92F at EXCHANGE.trad.tradestation.com>

  | When you have a server farm of over 200 high-end multicore machines,
  | eeking a little more performance out is worth some programmer time, as
  | compared with the price of buying more servers.  Even 1% is basically 2
  | more machines on the rack, with its inherent cost of ownership.

What kind of applications are you running that call mktime() enough that
even if you reduced mktime()'s CPU cost to 0 you could possibly save 1%
of the total system CPU usage?

Have you measured this saving, or are you just speculation, as in "this
is obviously faster so it must be worthwhile" ?

If you were concerned more about low end embedded systems I'd tend to
be a little more believing, but for high end multi-core machines if
you can even measure the cost of mktime (unless you have very unusual
applications) I'd be astounded.

It certainly is not where I'd be spending my programmer effort!

  | Basically, I found me a niche where performance still matters <grin>.
  | www.tradestation.com.

Performance matters just about everywhere, and if you can convince us
(which does not necessarily mean me - in fact almost certainly doesn't)
that there's actually a measurable performance win from the change,
then it might get considered, but that has to be in an overall system
context, not in a bogus "run mktime() a million times and count the
cost" test.

  | Actually, I think that the more complex line of code isn't _that_
  | complex, and saves a lot.

I suspect it saves some of the cost of mktime() which for most
people is saving some of nothing...

  | The real issue is testing.  "Check everything" is less likely to have
  | a mistake.  I'm actually making a comprehensive test which checks
  | every 15-30 minutes from 1930 through 2010, for every TZ file.

Why stop at 2010?   That's a little close.

Also remember, this is mktime() - it has to convert all kinds of
(bogus) struct tm's into a time_t - fully testing it is non-trivial.

  | Since I'm dealing with local times of various places in the application,
  | a major difference is to make timezone objects that can be instantiated,
  | rather than a single global setting.

That certainly seems worthwhile.

  | BTW, what is the official way to refer to or cite this code and the
  | associated database?  I see several names and abbreviations in use.

Very good question, and again, I will defer to someone who might
have a suggestion ("The ado timezone package" is probably what I'd use).

kre