[tz] Missing functionality (general question) - C11 functions, Localization, etc...

random832 at fastmail.us random832 at fastmail.us
Thu Mar 21 17:08:39 UTC 2013


In working on a windows/MSVC port of tzcode, I have run into the issue
of functions that MSVCRT implements that tzcode does not, and the
question of how much of it to implement. Part of the reason you haven't
heard anything more from me even though I've had the code itself
building for weeks is that it's hard to really determine when I can
declare it "finished".

Some of it are newer standard functions (wcstime from C95, localtime_s
from C11), some are functions created by microsoft that no-one else has
(_dstbias to match timezone and daylight, _mkgmtime which is their name
for timegm, _wctime which is a wide character version of ctime), some of
it is an artifact of them simultaneously supporting 32- and 64-bit
time_t, and some of it are old unix functions (e.g. ftime) that MS
happens to implement and tzcode does not.

Some of these functions are problematic to implement in a third-party
library. The means by which localtime_s and others in that family are
meant to call their error handlers is not specified in C11, and MSVC
uses a different (and nonstandard even though the standard was proposed
by microsoft) mechanism from slibc.


There's also miscellaneous other bits of missing functionality. strftime
provides some localization functionality for months and weekdays, but
not for e.g. %E and %O or for timezone abbreviations.

Also, since the tzdata file format itself contains no provision for
localization, I can't think of any C implementation that _does_
implement localized timezone abbreviations (I think there are some in
other languages that use the tz data in combination with the CLDR data)
As an aside, support for localized timezone abbreviations might be a
solution to the AEST/EST half of the australian timezone debate. I get
the impression (based on a comment in the section on Canadian timezones)
that it was decided in 1994 that localization would be someone else's
problem, and this was never revisited, nor actually became anyone else's
problem.

More than this, my main question is - what is the role of tzcode - the
library functions, that is, not the tools - itself? Is it simply a
reference implementation, to be used by libc maintainers and integrated
into their libraries as they see fit? Is it meant to be used as a
drop-in replacement for the system libc's time functions by application
developers who need consistent timezone handling? In short - is there a
roadmap for adding new functionality to tzcode, and/or is there any
reason _not_ to do so besides not having anyone volunteering to work on
it (I can look at it, but I don't want to if it's going to be rejected,
or if there's no point)

-- 
Random832


More information about the tz mailing list