wxDateTime is still broken with respect to DST outside of the standard
time_t range, but make a special exception for the dates near Unix epoch
when using BST as not accounting for DST for them broke the unit tests
when run in this time zone.
Note that constructing the dates outside of the standard range is broken
too, so if this problem is ever fully fixed in GetTm(), it would need to
be fixed in Set() too, where the DST is not taken into account neither.
The problems in unit tests were due to using the (correctly behaving)
standard mktime() for 1970-01-01 but then using our (broken) GetTm() for
accessing them and could, in principle, be also worked around by not
using mktime() for this date, but it seems better to keep correct
behaviour at least for it, even if it's still broken for many earlier
dates.
See #15370.
Take into account that from 1968-10-27 and until 1971-10-31 UK used BST
time instead of GMT, i.e. that DST was permanently on.
This fixes unit test failures in BST time zone for the dates around the
Unix epoch of 1970-01-01.
See #15370.
Don't rely on time zone offset to check whether it is local as this
doesn't, and can't, work for the local time zone in Great Britain which
uses the same offset as UTC, but does use DST, unlike the latter.
Add a unit test (albeit disabled by default) checking that the code that
previously didn't work correctly in BST does work now (run the tests
using "TZ=Europe/London ./test wxDateTime-BST-bugs" under Unix to test).
Closes#14317, #17220.
See #10445.
Replace exactly the same code occurring in both wxDateTime::GetTm() and
Format() with a single version in a new wxTryGetTm() function.
No real changes yet, except for removing of some useless asserts.
This function tries to determine the preferred first day of week to use in
calendars. The procedure for obtaining this information is highly
platform-dependent, and is not possible on all platforms; in that case
Sunday is used as the fallback value.
Implementations are included for MSW, OSX, and Linux.
No real changes, just use DST_OFFSET constant instead of 3600 and remove the
"FIXME" comments as we're not actually going to fix anything here but will
just continue to assume 1 hour shift for DST.
This reverts commit aaddf6be7f as it broke
handling of dates when local time zone is BST, whose offset not counting DST
is 0, as for UTC, but which still should be handled as local timezone,
see #17220.
With the current wxDateTime handling of time zones, FromTimezone(Local)
doesn't make much sense anyhow, so abandon attempts to try making it work as
to really do it we need to specify the time zone being converted from too, as
explained in the second point of #10445.
See #16585.
Windows CE doesn't seem to be supported by Microsoft any longer. Last CE
release was in early 2013 and the PocketPC and Smartphone targets supported by
wxWidgets are long gone.
The build files where already removed in an earlier cleanup this commit
removes all files, every #ifdef and all documentation regarding the Windows CE
support.
Closes https://github.com/wxWidgets/wxWidgets/pull/81
Local time zone already logically includes DST, even if its offset doesn't
account for it (because the offset depends on the date, so it can't be part of
TZ itself), so don't add it again when converting to/from it.
Closes#16585.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77899 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
It was just added as a private function to implement %V format specifier
support, just extract and document it as it could possibly be useful in its
own right.
See #11857.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76989 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This compiler is not being developed since several years and almost certainly
can't be used to build the current wxWidgets sources anyhow, so remove all
support for it, including a lot of extremely ugly workarounds for its bugs
with template functions.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76546 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Make overriding virtual methods more explicit and enable additional checks
provided by C++11 compilers when "override" is used.
Closes#16100.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76173 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Always move the dates invalid due to DST (i.e. falling into the "missing" hour
on the DST start date) forward, as GNU libc does, even when using a different
CRT implementation, such as MSVC one which moves the invalid dates backwards.
This seems more expected and also fixes an especially bad problem which
happened due to moving the date backwards in Brazilian time zone where DST
starts at midnight as doing this changed the day and totally broke ParseDate()
assumption that setting wxDateTime to 00:00:00 at the given date really did
set it to this date.
Closes#15419.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74777 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This keyword is not expanded by Git which means it's not replaced with the
correct revision value in the releases made using git-based scripts and it's
confusing to have lines with unexpanded "$Id$" in the released files. As
expanding them with Git is not that simple (it could be done with git archive
and export-subst attribute) and there are not many benefits in having them in
the first place, just remove all these lines.
If nothing else, this will make an eventual transition to Git simpler.
Closes#14487.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74602 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The code took into account the possibility that the days in the beginning of
the year might belong to the last week of the previous year but not that the
days at the end of the year could belong to the first week of the next year.
Closes#14973.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73402 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Correct the test for negative spans less than a month and use the correct
month for computing the number of days in it.
Also add unit tests for problematic cases.
Closes#14704.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@72616 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This method returns the difference between the dates as wxDateSpan, unlike the
existing Subtract() and overloaded operator-() that return wxTimeSpan.
Closes#14704.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@72600 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This change prepares the way for using wxGTK under Windows as this would
still define __WINDOWS__ but use __WXGTK__ instead of __WXMSW__.
Closes#14064.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@70796 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The internal wxDateTime representation is in the UTC, so use
wxGetUTCTimeMillis() in UNow(), using wxGetLocalTimeMillis() made it
inconsistent with Now() and wrong.
Really closes#13862.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@70418 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
These functions are used by wxGetTimeZone() defined in time.cpp and so need to
be available from wx/time.h. This is also the most logical place for them.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@69846 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
When deducing the time zone from struct tm tm_gmtoff field, query tm for the
current time and not the Epoch as the DST rules -- and hence the time zone
offset -- could have changed since 1970. This is notably the case for Ireland
which used a different time zone from 1968 to 1971.
Notice that GetTimeZone() still must return the time zone without taking DST
into account, so we explicitly compensate for DST if it's in effect.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@69689 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
If a locale doesn't use AM/PM strings, strftime() can return an empty string
which does not indicate an error, so don't assert that strftime() failed in
this case.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@69411 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Try to make the chain of preprocessor checks for different ways of getting
time zone from the CRT more clear.
Also call _tzset() for all MSVC versions, not just MSVC8+ (closes#12700). We
should probably call tzset() for the other compilers too, in fact.
And multiply the timezone returned from ftime() by 60 as it's supposed to be
in minutes and not seconds as needed.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66245 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We must call _tzset() before calling _get_timezone() as while this is normally
done implicitly by the other time functions, it might not have been done yet
if create a wxDateTime::TimeZone before calling any of them.
Closes#12700.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66241 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Check that the provided day is strictly positive and also that the month is in
valid range: while it should always be, considering that it's an enum element,
in practice people often cast ints to wxDateTime::Month with potentially fatal
results. Catch this with an assert in wxDateTime::Tm::IsValid().
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66203 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Apparently the MSDN documentation for VC8 is wrong and _get_timezone()
function expects a long and not int when using it (as is already the case with
VC9 and VC10).
Closes#12653.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66013 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
While some (but not all) versions of VC8 CRT still define _timezone variable,
it is deprecated and shouldn't be used and referencing it can result in
linking problems if it pulls in static CRT.
Just use _get_timezone() function instead for the VC versions that support it
(as was already done in r54417 for VC8 in 2.8 branch).
Closes#4691.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65994 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
There doesn't seem any reason to allow access to all the other struct Tm
fields but not yday so make it public, fill it in correctly when creating Tm
without using its ctor from struct tm and document struct Tm itself including
its yday field.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65649 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Set Tm::yday to a fixed value in the ctor as well instead of not initializing
it at all.
This bug actually didn't have any visible consequences as yday is currently a
private member of struct tm and didn't seem to be used anywhere but it at
least avoids MinGW 4.x warnings about possibly uninitialized variable and
might become important in the future if we allow accessing this field.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65648 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Native month calendar functions doesn't always return correct values in the
time part of SYSTEMTIME so ignore it and use just the date component.
To simplify doing it, add helper (MSW-specific) SetFromMSWSysDate() and
GetAsMSWSysDate() functions which convert between wxDateTime and SYSTEMTIME
but take only date component into account.
This commit partially replaces changes of r63560 and closes#11276.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64208 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
HOURS_PER_DAY was used only in the part of the code which was moved to
src/common/datetimefmt.cpp and some compilers (e.g. IRIX mipsPro) now warn
about an unused static constant in datetime.cpp, so just remove it from there.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@63572 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This function was implemented in terms of GetWeekOfYear() which made it tricky
to get it right as GetWeekOfYear() can, correctly, return week number for the
previous year for the first days of January (and also from the next one for
the last days of December).
Replace this implementation with a simple one directly counting the number of
weeks since the first of the month, this seems to be much simpler and does
pass the new unit test case which the old version failed.
Also make the unit test failures more informative by using
WX_ASSERT_EQUAL_MESSAGE() instead of CPPUNIT_ASSERT_EQUAL().
See #11561.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62916 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxDateTime::SetFromMSWSysTime() and GetAsMSWSysTime() worked with the date
part of SYSTEMTIME only, do use time part as well now.
Closes#11176.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@61842 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
DAYS_PER_400_YEARS was erroneously used instead of DAYS_PER_WEEK which
resulted in creation of much larger object file than needed as the array is
initialized.
Closes#11143.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@61765 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
