Document Curl_gmtime() and define away the old functions so that they
won't be used internally again by mistake.

Instead of polluting many places with #ifdefs, we create a single place
for this function, and also check return code properly so that a NULL
pointer returned won't cause problems.

The date format in RFC822 allows that the seconds part of HH:MM:SS is
left out, but this function didn't allow it. This change also includes a
modified test case that makes sure that this now works.

Reported by: Matt Ford
Bug: http://curl.haxx.se/bug/view.cgi?id=3076529

  that now makes curl_getdate(3) actually handles RFC 822 formatted dates that
  use the "single letter military timezones".
  http://www.rfc-ref.org/RFC-TEXTS/822/chapter5.html has the details.

for a better API to date parsing than the external API is

inclusion by the curl tool without colliding with the curl_strequal functions.

run-time relocations.

used in strequal.c so now all test cases run fine for me again.

  (http://curl.haxx.se/bug/view.cgi?id=2154627) which pointed out that libcurl
  uses strcasecmp() in multiple places where it causes failures when the
  Turkish locale is used. This is because 'i' and 'I' isn't the same letter so
  strcasecmp() on those letters are different in Turkish than in English (or
  just about all other languages). I thus introduced a totally new internal
  function in libcurl (called Curl_ascii_equal) for doing case insentive
  comparisons for english-(ascii?) style strings that thus will make "file"
  and "FILE" match even if the Turkish locale is selected.

because the struct is declared on the stack and not all members are used so
we could just as well make struct with only struct members we actually need.

  date parser function. This makes our function less dependent on system-
  provided functions and instead we do all the magic ourselves. We also no
  longer depend on the TZ environment variable.

is not ANSI C, just a common extension.  This caused problems on
at least Open Watcom C.

(http://curl.haxx.se/bug/view.cgi?id=1863171) where he pointed out that
libcurl's date parser didn't accept a +1300 time zone which actually is used
fairly often (like New Zealand's Dailight Savings Time), so I modified the
parser to now accept up to and including -1400 to +1400.

use that prefix as we use that prefix only for library-wide internal global
symbols.

while () => while()
and some other minor re-indentings

(http://curl.haxx.se/bug/view.cgi?id=1230118) curl_getdate() did not work
properly for all input dates on Windows. It was mostly seen on some TZ time
zones using DST. Luckily, Martin also provided a fix.

could very well cause a negate number get passed in and thus cause reading
outside of the array usually used for this purpose.

We avoid this by using the uppercase macro versions introduced just now that
does some extra crazy typecasts to avoid byte codes > 127 to cause negative
int values.

the MEST and CEST time zones.

zone name of a daylight savings time was used. For example, PDT vs PDS. This
flaw was introduced with the new date parser (11 sep 2004 - 7.12.2).
Fortunately, no web server or cookie string etc should be using such time
zone names thus limiting the effect of this bug.

seems the Windows (MSVC) libc time functions may return data one hour off if
TZ is not set and automatic DST adjustment is enabled. This made
curl_getdate() return wrong value, and it also concerned internal cookie
expirations etc.

VS2005.

that feature 64 bit 'long'.

Some systems have 64 bit time_t and deal with years beyond 2038. However, even
some of the systems with 64 bit time_t returns -1 for dates beyond 03:14:07
UTC, January 19, 2038. (Such as AIX 5100-06)

week day names and month names and servers don't like that.

it anymore

I was previously #ifdef'ing to a different look when this parser is used