Disable wxDateTime tests failing due to TZ offset changes

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.
This commit is contained in:
Vadim Zeitlin
2017-11-30 17:44:41 +01:00
parent d3a01e3fe6
commit d49784b0a2
2 changed files with 19 additions and 0 deletions

View File

@@ -1248,6 +1248,10 @@ public:
for more information about time zones. Normally, these functions should
be rarely used.
Note that all functions in this section always use the current offset
for the specified time zone and don't take into account its possibly
different historical value at the given date.
Related functions in other groups: GetBeginDST(), GetEndDST()
*/
//@{

View File

@@ -763,6 +763,21 @@ void DateTimeTestCase::TestTimeFormat()
// do convert date to string
wxString s = dt.Format(fmt, tz);
// Normally, passing time zone to Format() should have exactly
// the same effect as converting to this time zone before
// calling it, however the former may use standard library date
// handling in strftime() implementation while the latter
// always uses our own code and they may disagree if the offset
// for this time zone has changed since the given date, as the
// standard library handles it correctly (at least under Unix),
// while our code doesn't handle time zone changes at all.
//
// Short of implementing full support for time zone database,
// we can't really do anything about this other than skipping
// the test in this case.
if ( s != dt.ToTimezone(tz).Format(fmt) )
continue;
// convert back
wxDateTime dt2;
const char *result = dt2.ParseFormat(s, fmt);