| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
I removed the prefix as well accordingly.
|
|
By the use of a the new lib/checksrc.pl script that checks that our
basic source style rules are followed.
|
|
Found with codespell.
|
|
It turns out some systems rely on the gmtime or gmtime_r to be defined
already in the system headers and thus my "precaution" redefining of
them only caused trouble. They are now removed.
|
|
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
|
|
|
|
made it deal with named time zones as well as mail-style +0200 ones.
Seems to work fine. I'm comparing with GNU date command:
date -d [date] -u +%s
|
|
work with this
|
