Kees Dekker wrote:
Regarding date.c:
Thanks for your comments. date.c is mostly a proof-of-concept for tzdata; as far as I know, no downstream package is actually using it, and it's intended more to demonstrate the API than anything else. That being said, we might as well keep date.c up-to-date (so to speak), so....
date.c is very *NIX centric. Windows does not have utmp.h (is not POSIX either)
The utmp.h-related code is very old, and predates POSIX. As POSIX standardized on utmpx.h in the 1990s, it's time to remove the old utmp.h code. I've done that in proposed patch #1 (attached). This should remove any need for ifdeffing utmp.h out.
I was a little bit surprised that no _WIN32 defines exist in your code...
There are many operating systems and they are constantly mutating, and we don't have the time or inclination to maintain code that depends on _WIN32, __WIN32__, __CYGWIN__, _AIX, __hpux, etc., etc. Instead, we have specific macros dealing with specific features (e.g., HAVE_UTMPX_H), and it's the responsibility of whoever's porting code to a particular platform to set the macros accordingly. The defaults are intended to be suitable for a standard POSIX environment. Now that you mention it, though, date.c has portability problems other than utmp, problems that also come from the fact that date.c was written before POSIX was standardized. While we're at it we might as well modernize date.c to use current POSIX interfaces in these other areas, so I did that in proposed patch #2 (attached). This removes some rarely-used options (usable only by 'root') in date.c, options that weren't portable anyway. These proposed patches are installed in the experimental version on Github; please base further comments on the Github version.