"%T" was only handled when strftime() could be used but not by our own
implementation, resulting in failing to handle it for format string
including both "%T" and one of the specifiers not supported by the
standard function, such as "%l" or several others when using MinGW.
Closes#26179.
wxDateTimeChristianHolidays was tested with a wxDateTimeUSCatholicFeasts
already existing and taking precedence. I.e. the tests for Christmas in
ChristianHolidays actually tested (again) the USCatholicFeasts
implementation.
This reveals an off-by-one bug in wxDateTimeChristianHolidays::DoIsHoliday(),
which doesn't use the enum symbol for month, and declares Christmas to be
on the 25th day of the 13th month.
Further, this raises the question whether it is a bad idea to have the
authority implementations in a header. Fixing bugs like this would
require recompiling the application, instead of simply updating the
DLL/dylib.
TestTimeTicks() checks were skipped for test dates with gmticks == -1,
ensure that these tests really run by providing the expected ticks
values.
See #24442.
Changes of a08c710b38 (Merge branch 'y2k38-fixes', 2024-04-14) broke
support for dates with year > 3000 when using MSVC CRT with 64-bit
time_t as it still doesn't support such dates even if they fit into the
type range.
Fix this by restoring the use of our own code instead of using CRT in
this case.
See #24464.
Closes#25228.
This is not really used when parsing, but we still need to support the
GNU extensions to the strftime() formatting specifiers used to change
padding, as they can (and do, at least in the case of "%-d" and "%-m")
occur in the locale descriptions and so can be used when parsing dates
using the current locale format.
Closes#24533.
This test shouldn't run when "[datetime]" or another tag is specified on
the command line as it always fails in non-BST time zone, so only run it
if it's explicitly selected by name.
This includes a static function to calculate Easter that can be used for
other authorities.
Document the wxDateTimeWorkDays and wxDateTimeHolidayAuthority classes.
Closes#24094.
ParseDateTime() currently fails if there is a 'T' separator in front of
time component. FormatISOCombined() uses this separator as the default,
so wxDateTime can't parse its own formatted results by default.
This commit fixes that issue by allowing an optional 'T' between the
date and time parts.
Closes#22999.
This is a combination of running clang-tidy with modernize-use-nullptr
check for some ports (GTK, X11, OSX) and manual changes to the ports for
which it couldn't be used easily (MSW, DFB) and also manually updating
the docs.
Also replace NULL with null or nullptr in the comments as this is more
consistent with the use of nullptr in the code and makes it simpler to
grep for the remaining occurrences of NULL itself.
And also use null in the assert messages.
Only a few occurrences of "NULL" are still left in non-C files, mostly
corresponding to unclear comments or string output which it might not be
safe to change.
Simply use INFO() to give all the information we want to see in case of
failure once instead of doing it in multiple WX_ASSERT_MESSAGE() in a
more ugly way with extra parentheses.
Also use FAIL_CHECK() to keep running the test after the first failure.
Accept the same kind of time zone specifiers that RFC822 timestamps
accept; most importantly the "+0200" style.
Added more tests, and changed the way tests compare dates:
Since some timestamps now specify a time zone, those need to be compared
as UTC to avoid the system's time zone affecting the tests. Others can
still be compared as local time, as before.
Out-of-bounds was already covered by the fact that the date is appended 32
zero-bytes in ParseRFC822Date() as a safety measure. But now the time zone
parsing section of the function no longer relies on those extra zeros
being present.
Added tests for RFC822 timestamps with military time zones, and more types
of truncated, invalid time zone specifiers.
Correction to the commit:
2153ffc (Test ParseRFC822Date() with truncated time zone specifiers,
2022-03-19)
The inputs failed as expected, but due to an unrelated reason (missing
comma).
Set the end iterator to the end of the actually parsed date, instead
of consuming any ultimately unparsed whitespace/delimiters possibly
following the date.
In other words, check that the unprocessed part of the input is what
we expected.
Also add some cases where a valid date or time is followed by something.
The intent of the implementation clearly is to allow parsing time first,
date second. But this failed, because a time such as "14:30:15" would
successfully parse as a date (as 14th of current month, current year).
Consequently an attempt is made to parse the actual date as time, which
fails, and therefore the whole ParseDateTime() fails.
Adding a failing test case for ensuring times cannot be parsed as dates
does not cause a failure, because partially yet successfully parsed inputs
get silently ignored (in both ParseDate and ParseDateTime tests). Fixing
both of these, too.
Closes#22203.
The RFC accepts 2-digit years, and it makes most sense to interpret
e.g. 95 as 1995. However, this is an incompatible change, as earlier
95 was literally decoded as 95 AD.
Years 00..29 are considered to mean 20xx; 30..99 means 19xx.
Closes#22196.
The implementation implicitly relies, in many places, on the assumption
that the input never ends prematurely. If it does, the iterator
pointing beyond the end of buffer is dereferenced, which is UB.
The solution used here is to append 32 zero bytes to the date string,
which hopefully keeps the code more readable than checking for the end
of string before each deference operation.
Add various syntactically invalid inputs to unit tests.
Closes#22185.
This will allow using this class in the library code too.
No real changes yet, this is a pure refactoring.
This commit is best viewed using git --color-moved option.
This was added back in b5f85206a9 (fix ParseFormat("%d") to set the date
it finds (#10002), 2008-09-26), but the test didn't do what the comment
said and didn't use the default date object it added.
Fix this now to finally do what was intended all these years ago.
Retrying immediately wasn't very useful, as the times must have been the
same during all loop iterations anyhow, so add a sleep to try to finally
fix the sporadic test failure on Travis.
Avoid spurious error in the unit test by calling Now() and UNow() a few
times in a row until they return the same second, as we may be unlucky
enough for this not to be the case when we call them just once.
This is its actual behaviour and it's the right thing to do, as it's
consistent with Now() -- even though the documentation wrongly stated
otherwise (since 324ab5e2db).
Also add a unit test checking that UNow() == Now(), except for the
milliseconds.
See #14148.
Closes#18524.
Closes https://github.com/wxWidgets/wxWidgets/pull/1594
There were many dozens of such warnings given for the various arrays
used in the tests and it just doesn't seem feasible nor desirable to fix
them all, so just suppress the warnings for all these arrays to get rid
of them with recent (7+?) versions of gcc.
Converting to another time zone and dealing with DST is completely
useless here, ticks values are always in UTC, so we can just use UTC
values from the beginning.
This ensures that dates are printed out correctly if comparing them
fails.
It might be better to avoid always including this header, but this is
the simplest solution.
No real changes, as this doesn't affect this test, but use the new
IsLocal() method instead of comparing the time zone offset with the time
zone, which doesn't work correctly for BST.
wxDateTime timezone-related methods always use the current timezone
offset, while other methods, using CRT, use correct value for the given
date, which may be different.
This discrepancy accounted for test failures in Europe/Minsk time zone
as Belarus has switched from UTC+2 to UTC+3 since 1999 date used in the
test.
It is impossible to really fix the problem easily, so just skip the test
in this case and also mention this bug in the documentation.
See #15370.
Show the loop variable when doing checks inside a loop to make it more
obvious for which test case the failures occur.
Also use CHECK(), instead of REQUIRE(), to which CPPUNIT_ASSERT_EQUAL
expands, to continue with the other loop iterations after failure.
No real changes, just show the variable values if any checks fail and
also continue running the test for the other data points even if one of
them fails.
dxbjavidandVadim Zeitlin
Lauri NurmiandVadim Zeitlin
Blake-MaddenandVadim Zeitlin
Blake-MaddenandVadim Zeitlin
Paul Cornett
PB