Missing functionality (general question) - C11 functions, Localization, etc...
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
On 21/03/13 18:08, random832@fastmail.us wrote:
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. [...] I would begin by asking you what do you mean by a port of tzcode, I would usually understand that as making sure all functions provided by tz compile and work under windows/MSVC, but you seem to want something more like 'reimplement based in tz all time related functions available in Windows'.
On Thu, Mar 21, 2013, at 14:43, Ángel González wrote:
I would begin by asking you what do you mean by a port of tzcode, I would usually understand that as making sure all functions provided by tz compile and work under windows/MSVC, but you seem to want something more like 'reimplement based in tz all time related functions available in Windows'.
All time related functions _in MSVCRT_. I'm not talking about implementing the SystemTime/FileTime/etc family of functions from kernel32.dll, or even time(). You do realize that tzcode implements important C library functions like tzset, right? Substituting its implementation of tzset will make any remaining MSVCRT functions simply fail to function at all: i.e. if I leave MSVCRT's localtime_s alone, it won't know what timezone it's in because the internal variables set by MSVCRT's tzset never got set. Some of these are standard functions, too - as I mentioned, the localtime_s (and related functions) are in a C11 annex. ftime isn't a function unique to microsoft, it's an old unix function. The locale support I was talking about for strftime isn't even related to the port, I was just being thorough in listing all missing functionality I'd noticed. Now, those problems aren't necessarily real problems _if absolutely nothing but zdump is ever going to use it_, which is part of why I was asking,, what is the purpose of tzcode (and specifically of the library functions in it). If it's just meant as a reference implementation, or just to support zdump, then none of this is necessary. But then why build libtz.a at all?
On 21/03/13 20:33, random832@fastmail.us wrote:
All time related functions _in MSVCRT_. I'm not talking about implementing the SystemTime/FileTime/etc family of functions from kernel32.dll, or even time().
You do realize that tzcode implements important C library functions like tzset, right? Substituting its implementation of tzset will make any remaining MSVCRT functions simply fail to function at all: i.e. if I leave MSVCRT's localtime_s alone, it won't know what timezone it's in because the internal variables set by MSVCRT's tzset never got set.
Some of these are standard functions, too - as I mentioned, the localtime_s (and related functions) are in a C11 annex. ftime isn't a function unique to microsoft, it's an old unix function. The locale support I was talking about for strftime isn't even related to the port, I was just being thorough in listing all missing functionality I'd noticed. Have you checked what is implemented in ReactOS?
On Thu, Mar 21, 2013, at 15:54, Ángel González wrote:
Have you checked what is implemented in ReactOS?
I don't understand how that's relevant to my question. I'd need to make new implementations of the functions anyway because existing code isn't public domain licensed anyway. As it happens, localtime_s does exist in ReactOS, but is not implemented correctly. Anyway, the talk about the MSVC port was just a prelude to my main question, explaining how I got to the point of looking at these issues.
On 03/21/2013 10:08 AM, random832@fastmail.us wrote:
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?
It can be used either way. It would be nice if it could support any relevant C11 time features that it doesn't already support. The main problem, I expect, has been lack of time. wcsftime has been low-priority since few non-Microsoft developers care about wide-character support. localtime_s, gmtime_s. etc. are not required by the standard and these functions, like the other C11 Annex K functions are somewhat controversial, so they've been low priority too. But if these functions could be added without much disruption to the existing code base, I can't imagine anyone would object.
If it's just meant as a reference implementation, or just to support zdump,
It can be used to support zdump, but it's not required for that. You should be able to build zdump with any reasonably-conforming implementation of localtime etc.
participants (3)
-
Paul Eggert -
random832＠fastmail.us -
Ángel González