-1 on success and 0 on failure. Luckily, no caller has been checking the return
value.

the wrong timezone (off by an hour) because we were passing an uninitialized
time_t value to localtime_r(). -- oops.

time was in effect, year-round, on Linux.

Use the localtime() tm_gmtoff method of detecting the local time zone offset
on Linux, don't rely on the global variables 'timezone' and 'daylight'
behaving as they did in Borland C/DOS. From the Linux man page:
 Note that the variable daylight does not indicate that daylight  saving
       time  applies  right now.

Test for sdl12-config before sdl-config for systems that have SDL 2.0
installed as sdl-config.

in pthread_once().

asprintf() now.

the expanded specified with or precision was more than one digit long.

tools (caused build failure on redefinition of functions).

Rename entry_buf to int_buf since it only ever holds an integer now.

value for the Win32 asprintf().

if I can reuse a va_list argument.

rename to parse_byte_count(), so we can use it more places (e.g. jsexec).

used to, that is, it stores the broken-down date/time values in the time_t
equivalent for the local timezone, regardless of what value is in the zone
element of the xpDateTime_t.

_mkgmtime() however didn't appear until MSVCR80.dll, so the current use of
MSVCRT.DLL is broken and SyncTERM won't build.

to the local timezone equivalent (not adjusting for offset). Now using timegm()
(aka mkgmtime()) to fix this scenario. Times in zones other than the local time
zone or UTC are explicitly not supported by this function now (returns
INVALID_TIME in that scenario).

equivalent to sane_mktime() for broken-down date/time's in UTC.

from xpdatetime.c to support more date string formats (e.g. the JavaScript
Date.toISOString() format).

failed login attempt client IP addresses on Windows.

If DigitalMan uses the Edit and Continue feature, he can fix it.  :-)

passed string on commas, tabs, spaces, newlines, and carriage returns and
eliminating empty entries.

(only impacts active FTP transfers via IPv6).

really may to what is listed.

follow the special boolean keywords "True", "Yes", or "On", treat the value as
a logical true (1). Previously, if the boolean keyword was followed by a
semicolon (no whitespace separation) or any text with whitespace separation,
the value would be treated as a logical false (0). The  example sexpots.ini at
wiki.synchro.net has comments following some "true" values which caused them
to be interpretted as "false". Bug reported via reddit by FozzTexx.