On Oct 27, 2004, at 10:48 AM, Christopher Smith wrote:
So, I think in a perfect world, we'd want our logging package to depend on as few other libraries as possible. I'll have to look at the timezone code, but I have to think that there is some way to avoid the TZ problem using standard libraries.
I haven't been able to find a way to support timezones other than UTC and the current TZ in a portable fashion without mucking with the TZ environment variable.
I love ICU, but it seems like a huge library just to handle dates and times.
The only thing unique that ICU added to the table was a portable implementation mechanism for getting timezone rules (and maybe locale aware date/time formatting). If we didn't want to use ICU, the best alternative would be to use the Win32 API on that platform and attempt to parse the /usr/share/zoneinfo files on any other platform to get the timezone rules for an arbitrary TimeZone and then use the offset with APR's formatters. I assume that deep in glibc there is code that reads zoneinfo binary files, but it does not appear to be accessible. The binary format however is well documented and writing a reader would not be impossible. I assume (but haven't checked) if that is how ICU gets the info on most platforms.
If we do need libraries for threads and dates, I'd be tempted to look at the boost thread and date_time libraries. Do they have the functionality needed?
boost::date_time doesn't appear to have any facility to get timezone rules. Using Boost would likely introduce a lot of licensing issues that use of APR would avoid.
I'm currently writing test cases for log4j's date formatting to determine what it actually supports. I'm finding some strange behavior and will probably raise that on the log4j dev mailing list tomorrow. After I figure out what log4j does then I'll port those tests over to log4cxx and see what is missing.
