summaryrefslogtreecommitdiffstats
path: root/src/corelib/time/qtimezoneprivate_win.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Make QTimeZonePrivate::Data construction easierEdward Welbourne7 days1-5/+5
| | | | | | | | | | | | | | Turn QTZP::invalidData() into a default constructor. A second constructor taking needed details avoids exercising that default constructor elsewhere, when the invalid values aren't what we need. All constructed instances now have all members initialized. In the TZ backend, add some PosixZone helpers to create Data objects, reducing the complexity of calculatePosixTransitions(). Task-number: QTBUG-122619 Change-Id: I56557a2f6249d60012355d5d72c662474be76e51 Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
* QWinTimeZonePrivate::availableTimeZoneIds(): cache resultEdward Welbourne2024-01-251-7/+10
| | | | | | | | | | | | | | | This follows up on commit d59e539b3a1252aa22783c4fdf1e22b35e5a4292, doing the same for one of its callers. The mapping from windows IDs to IANA ones is hard-coded (using CLDR-generated data), so the (now unchanging) availableWindowsIds() list shall always map to the same list of IANA IDs. Pick-to: 6.7 6.6 6.5 Task-number: QTBUG-120682 Change-Id: I4d610c24110064236b375cab04cde90bbe07735f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Implement a TODO: cache the list of MS TZ IDsEdward Welbourne2023-11-241-14/+16
| | | | | | | | | | | | | | | | | | | | | The MS TZ-backend's lookup of available Windows IDs included a TODO advocating caching the result, since it is unlikely to change at runtime. Given that MS's time_t functions don't believe in times before 1970 and two-digit year parsing (such as the ASN.1 parser does, apparently many times, during SSL handshakes) assumes the 1900s (and certs in use today have mostly been issued this century), SSL involves DTP falling back repeatedly to lookups of local time's offsets from UTC (before it discovers it shouldn't have been using local time anyway) via the system timezone object, this cacheable list can be accessed many times. (A user has reported thousands per SSL socket created.) So let's implement that TODO and trust that updates to the registry's set of available zones aren't a common occurrence at runtime. Pick-to: 6.6 6.5 Change-Id: Iefe235c71da1bf5c3372c52dba89ad0657e06c0b Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Replace {add,sub,mul}_overload with q{Add,Sub,Mul}OverloadMarc Mutz2023-06-121-3/+3
| | | | | | | | | | | | | | | | | | | These APIs started out as private APIs in qnumeric_p.h, but have since been made pseudo-public in qnumeric.h. The qnumeric_p.h versions just forward to the qnumeric.h ones, so just use the latter. This is in preparation of removing the {add,sub,mul}_overflow versions, which, despite being defined in the unnamed namespace, don't sport the q prefix, so potentially clash with global symbols. The change is a simple textual search and replace, manually excluding qnumeric_p.h. Picking to 6.5 to avoid cherry-pick conflicts going forward. Pick-to: 6.6 6.5 Change-Id: Ic0f7c92f7c47923317109e8a9dc06fa66bdff2c2 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-161-39/+3
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* QtCore: replace QLatin1String/QLatin1Char with _L1/u'' where applicableSona Kurazyan2022-03-251-3/+5
| | | | | | | | | | | As a drive-by, did also minor refactorings/improvements. Task-number: QTBUG-98434 Change-Id: I81964176ae2f07ea63674c96f47f9c6aa046854f Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
* Correct handling of {next,previous}Transition before FIRST_DST_YEAREdward Welbourne2022-03-041-13/+61
| | | | | | | | | | | | | | | | | | | | | | | | A recent change introduced a cut-off in believing MS's claims that a zone has always had a yearly cycle of DST, to stop believing it before 1900, as no actual zone adopted DST that early. However, this was only applied to the data() method to get the data for a specified time; failure to do the same for {next,previous}Transition lead to inconsistent results and tripped up an assertion. The change to data() also failed to consider the situation of a southern hemisphere zone, for which the rule will claim the early part of the year was in DST; and init() should also mark an initial DST-recurrence rule as starting no earlier than 1900. Add corresponding FIRST_DST_YEAR checks to {next,previous}Transition() to be consistent with the one in data(), refine data()'s checking and amend init(). This amends commit 9a83706046406f233ea6f93a2f90fd5b05916ee9 Pick-to: 6.3 Fixes: QTBUG-100873 Change-Id: Ic9822b87caa01561bc0b7d0355963e4c80ef047c Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Fix inverted condition on year starting in DSTEdward Welbourne2022-03-041-3/+6
| | | | | | | | | | | | | | The first transition in a year with DST is *to* DST precisely if the year *doesn't* start in DST, not if it does. Also fix the startsInDst() check it's using there, which neglected the possibility that the year's DST transition might be faked. This amends commit d98b43005eed051a77beacb252c7a9eb7f5c4493 Pick-to: 6.3 Change-Id: I17422fa9972f826b5bf7e325f5e579f41300fd97 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Improve handling of newYearOffset in qtimezoneprivate_win.cppEdward Welbourne2022-03-041-9/+20
| | | | | | | | | | | | | | | | | | | In nextTransition() it wasn't being carried over from one rule to the next, as intended. It needs to be defined at function level, set for the first rule and updated for each new year tried. Also assert that it does faithfully reflect the standard time in rules without transitions. In the process of fixing that, since it's computed from the yearEndOffset() of a prior year, test whether that year is less than the rule start rather than whether the present year is less than or equal to it. As the prior year is immediately before the present year, this makes no difference, but it clarifies the reasoning. Apply this clarification also in data() and previousTransition() for consistency. Pick-to: 6.3 Change-Id: I29c41e67784eaae13b83f6ae1ad16509e636c187 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Consistently treat times before first rule as in its standard timeEdward Welbourne2022-03-041-38/+38
| | | | | | | | | | | | | | | | In QWinTimeZonePrivate::previousTransition(), an initial no-transition first rule was interpreted as implying a transition to its standard time at "the start of time". Do the same for times before the start of the first rule even if it is a DST recurrence; and, in data(), treat times before the first rule as being in its standard time. In the process, restructure data() to do that early return first, instead of in an else clause, so as to dedent the other branch of its code and make clearer how it fits into its outer loop. Pick-to: 6.3 Change-Id: I21482d904c33542bf04f6510b974c01817d7aa5f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix handling of out-of-range years in QTZP_winEdward Welbourne2022-03-041-9/+8
| | | | | | | | | | | | | | A transition outside the range of qint64 would be mapped to invalidMSecs(), the same as the fake-detection sets a fake transition to. This would have lead to a year at the boundary of qint64's range being mistaken for a fake-DST year. So replace the fakesDst() method, that compared transition times to invalidMSecs(), with an actual boolean member that gets set when detecting fake DST, so that the detection is correctly done. Pick-to: 6.3 Change-Id: Iadc80973bc033915733c4a4f4ccfdd3863025fb4 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Correct fake-DST detection and handling in QTZP_winEdward Welbourne2022-03-041-27/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | The end-of-year checks previously presumed they would accompany a zero daylight-savings change there; however, this misunderstands what a fake transition is doing. A fake at the end of the year means that the transition during the year is out of the time the fake claims it goes into, so the offset nominally in effect after the fake should match the offset the year started in, the same as for a year-start fake. However, implementing that exposed the fact that Bangladesh's brief flirtation with DST in 2009 ended at the end of the year, and MS's data has no other instance (aside from entirely bogusly claiming that Bhutan did the same in 2009) of an end-of-year transition, in particular no fake transitions. So the end-of-year case for faking does not arise and I've eliminated it from the code here. This greatly simplifies the code to detect fake DST rules. At the same time, in the ruleToData() wrapper, use the transition implied by isDst only if it isn't the fake one; the other is the only real transition in the year anyway, however described. Also, extract the detection of start-of-year transition times to a function and make it more exact. Pick-to: 6.3 Change-Id: Ide160d28e7cca37c224f40164ebe7f9a17f028e7 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use QDateTimePrivate's methods in preference to std::numeric_limitsEdward Welbourne2022-03-041-8/+7
| | | | | | | | | | | | | | | | The methods give them more appropriate names. This revealed one place where the min() that's actually invalidMSecs() was being used for a time that should have been in the supported range, so amend that to use minMSecs(). Replaced a use of invalidMSecs() + 1 with minMSecs(), to which it is equal, as that was the meaning it was used for. At the same time, make those methods constexpr (because they are) and [[nodiscard]], since their values should be used, while dropping their fatuous inline (the bodies are inline in the declarations). Pick-to: 6.3 Change-Id: Idcd51c55850573372b44e6fcf08d5d2665b8a60e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Correct handling of start-of-rule situations in QTZP_winEdward Welbourne2022-02-181-5/+7
| | | | | | | | | | | | | | A recent change made sure the handling of a time before the first rule would be handled correctly; but I wrongly supposed relevant code would only be exercised in that case. However, it is also run when the moment after which we want a transition is after the last transition in the rule for its year: we fall through to the next rule and need to find its first transition. This amends commit d98b43005eed051a77beacb252c7a9eb7f5c4493. Change-Id: Idb9114a2e272ff9cdb80312f33a0b1e6cd02d582 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Extract functions: move some code to TransitionTimePairEdward Welbourne2022-02-181-11/+18
| | | | | | | | | | Documenting the case where a year starts in DST belongs on the pair whose job is to work that out. The selection of which transition to report based on an isDst flag could be said once instead of thrice if made into a method there, too. Change-Id: Ice59bb8594097c53bc2fefe1706434462b225274 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Nail down handling of nextTransition() when before the first ruleEdward Welbourne2022-02-021-3/+12
| | | | | | | | | | | Avoid, for years before the first rule, a whole lot of complications needed when handling dates later than that rule's start. It is not entirely clear the code would previously have Done The Right Thing; it now is clear what it does. Change-Id: I00a79c0a4733f1deb0bbfecb03e1c64a104d08a3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Fix misguided winding backwards past start of start of MS TZ dataEdward Welbourne2022-01-301-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | QWinTimeZonePrivate::data()'s search for a rule applicable to a given time, in the first year whose milliseconds qint64 can represent, tries to look at the preceding year to get start-of-year data, which leads to misleading results. It does so to determine whether to use a rule's standard or daylight-saving details, but this year is long before the invention of daylight-saving time, so we can bypass the whole mess. Unfortunately, MS's data does pretend (in some zones) that DST has always been in effect, so cutting off that claim at some historical point will actually get better results for before the cut-off than for the period after it, until the relevant zone actually adopted DST. Conservatively put the cut-off at 1900, before any actual zone used DST, albeit after the idea was originally floated. This fixes a failure found by some QDate::{start,end}OfDay() tests that I want to introduce. Pick-to: 6.3 Task-number: QTBUG-99747 Change-Id: I15cf9dd092b946191e8863c7e85fbeb4ba6c106d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Refine QTZP_win's msecsToDate() by trusting arithmeticEdward Welbourne2022-01-301-3/+3
| | | | | | | | | | | | | | | | Division and modulo are guaranteed to be consistent, with the former truncating towards zero, so the latter giving a remainder that either is zero or has the same sign as the numerator. In particular, when the numerator is positive, the remainder is necessarily greater than minus it, so the formerly correct but unilluminating arithmetic necessarily gave the answer one and we can just --jd rather than doing anything cleverer. Assert the fact that ensures this. Pick-to: 6.3 6.2 Change-Id: Ia718bb947192f1fd2eb36549be12d30e4ee03d58 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Eliminate a constant from qtimezoneprivate_win.cppEdward Welbourne2021-11-181-6/+7
| | | | | | | | | Its MIN_YEAR was duplicating what's now provided by QDateTime::YearRange::First, so use that instead. In the process, tidy up an over-long line. Change-Id: I109f5435f63cb5cc97d54529a172b640f919dec0 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Remove some unused constants from qtimezoneprivate_win.cppEdward Welbourne2021-11-181-6/+3
| | | | | | | | | Recent commit 6845c444d082cfac561b3c8f28f53480ae066746 elicits warnings about two unused constants. Remove an unused macro at the same time, and add missing LL suffix to remaining qint64 constants. Change-Id: I4c84e10b512030e0e4f860d434382e62e6c936f5 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Avoid overflow for date-time in the first (partly) representable dayEdward Welbourne2021-11-111-2/+10
| | | | | | | | | | | | | | Computing the start of the first day's number of milliseconds since the epoch overflows, but adding enough seconds within the day would have brought us back inside the representable range. So, for days before the epoch, add a negative number of milliseconds from the end of the next day instead of a positive number of milliseconds from the (possibly unrepresentable) start of the target day. This is another a follow-up to commit 2b26dea51b26fff2ea955ad2b50c2c20194f0103 Change-Id: I2e0c68d7012db85dfe7da4a8a20ba95368178ed1 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Replace enum with constexpr qint64 variablesEdward Welbourne2021-11-111-7/+5
| | | | | | | It's the modern recommended way to do it. Change-Id: I10db128348014b316c1772d18396f272b0a2b766 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix 32-bit builds broken by mul_overflow() on qint64Martin Storsjö2021-11-101-1/+1
| | | | | | | | | Use std::integral_constant to avoid instantiating QIntegerForSize<16>, caused by 2b26dea51b26fff2ea955ad2b50c2c20194f0103 Change-Id: Ia6f49a1dcd82835c7e76200a650767fc519eab90 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix some out-of-range issues with time-zone supportEdward Welbourne2021-11-081-10/+19
| | | | | | | | | | | | | | | The MS-Windows back-end neglected to check for overflow when mapping date and time to milliseconds from the epoch. Add the checks for that and take care not to return qint64-min as a transition time - that's the invalidMSecs() value used as a special marker. QTimeZonePrivate::dataForLocalTime() neglected to handle the case of the backend being unable to answer offsetFromUtc() for one of the times requested, which the MS backend might. Change-Id: I6d7ee2cbf9aaf6678abb24a20e18b5cdac7f5a23 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use time-zone transition data before 1970 as well as afterEdward Welbourne2021-05-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QDateTime has long followed a convention of ignoring what it knows about time-zone transitions before the epoch. This produces unhelpful artefacts (such as an ahistorical spring-forward skipping the first hour of 1970 in Europe/London, which was in permanent DST at the time) and complicates the code. It documented that DST transitions were ignored, but in fact ignored all transitions prior to 1970 and simply assumed that the current time-zone properties (half a century later) applied to all times before 1970. This appears to be based on the fact that the MS APIs using time_t all limit their range to after 1970. Given that we have to resort to "other means" to deal with times after the end of time_t, when it's only 32-bit (and after year 3000, on MS systems), we have the means in place to handle times outside the range supported by the system APIs, so have no need to mimic this restriction. (Those means are not as robust as we might want, but they are less bad than assuming that the present zone properites were always in effect prior to 1970.) On macOS, the time_t functions only reach back to the start of 1900; it reaches to the end of its time_t range and Linux covers the whole range. Given this variety, the range is now auto-detected the first time it is needed (based on some quick and dirty heuristics). Various CET-specific tests now need adjustments in tests of times before the introduction of time-zones (when they are in fact on LMT, not CET). The systemZone() test of QTimeZone can now restore its pre-zone test cases. Various comments on tests needed updates. [ChangeLog][QtCore][QDateTime] Available time-zone information is now used to its full extent, where previously QDateTime used LocalTime's current standard time for all dates before 1970. Where we have time-zone information, it is considered reliable, so we use it. This changes the "best efforts" used for times outside the range supported by the system APIs, in most cases giving less misleading results. Fixes: QTBUG-80421 Change-Id: I7b1df7622dd9be244b0238ed9c08845fb5b32215 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add the "Territory" enumerated type for QLocaleJiDe Zhang2021-04-151-8/+8
| | | | | | | | | | | | | | | | | | | The use of "Country" is misleading as some entries in the enumeration are not countries (eg, HongKong), for all that most are. The Unicode Consortium's Common Locale Data Repository (CLDR, from which QLocale's data is taken) calls these territories, so introduce territory-based names and prepare to deprecate the country-based ones in due course. [ChangeLog][QtCore][QLocale] QLocale now has Territory as an alias for its Country enumeration, and associated territory-based names to match its country-named methods, to better match the usage in relevant standards. The country-based names shall in due course be deprecated in favor of the territory-based names. Fixes: QTBUG-91686 Change-Id: Ia1ae1ad7323867016186fb775c9600cd5113aa42 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Don't guess UTC when we can't find a system zone nameEdward Welbourne2020-09-281-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | If we're able to load a system zone without knowing its name, we shouldn't claim that its name is UTC. Instead, use the system zone information's name for the zone. Let the backend return an empty string if it can't determine the system zone ID, provided it has some way to get system zone info despite not knowing its name. This can happen on Windows if the system zone is one of Microsoft's idiosyncratic names that we don't recognize; or on Linux if /etc/timezone is a copy of a zoneinfo file, instead of a symlink. In support of that, handle empty ID as a request for system zone info, so that the backend constructors taking an IANA ID never get passed an empty ID; that gets routed to the default constructor instead. This incidentally restores QTzTimeZonePrivate's behavior, for empty ID, of reading the content of /etc/timezone if we are unable to determine the name of its zone any other way. Fixes: QTBUG-86306 Pick-to: 5.15 5.15.1 Change-Id: Iad57c18199124f651ebc3d32c3deffca6eaab512 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Remove winrtOliver Wolff2020-06-061-132/+0
| | | | | | | | | Macros and the await helper function from qfunctions_winrt(_p).h are needed in other Qt modules which use UWP APIs on desktop windows. Task-number: QTBUG-84434 Change-Id: Ice09c11436ad151c17bdccd2c7defadd08c13925 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Pass QDate and QTime by value in various static and local functionsEdward Welbourne2020-01-311-1/+1
| | | | | | | They're value types, so pass them as such. Change-Id: I0dc46c63a3a0e6d859b821362f71390f0148b64c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Win32: Consolidate registry codeFriedemann Kleint2019-10-141-56/+25
| | | | | | | | Add a RAII class for registry keys and use it throughout the code base. Change-Id: I666b2fbb790f83436443101d6bc1e3c0525e78df Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* MS TZ data: avoid calculating a date in year 0Edward Welbourne2019-09-131-13/+29
| | | | | | | | | | | | | | | | | | | | | | There is no year 0 in the proleptic Gregorian calendar, so QDate() won't be happy if asked for a date in it. Tweak scanning of the data we get from MS-Win so as to avoid a date calculation that could otherwise happen in year 0 when constructing QDateTime(QDate(1, 1, 1), QTime(0, 0, 0), QTimeZone("Australia/Sydney")). Added a test for this case, which Oliver Wolff has kindly verified does reproduce the assertion failure. However, Coin is unable to reproduce, as all its MS builds are configured with -release, so Q_ASSERT() does nothing. (The relevant code then skips over year 0, albeit for the wrong reasons, and gets the right results, albeit inefficiently, leaving no other symptom by which to detect the problem.) Fixes: QTBUG-78051 Change-Id: Ife8a7470e5bd450bc421e89b3f1e1211756fc889 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Separate out the time, zone, date code from corelib/tools/Edward Welbourne2019-06-061-0/+927
We'll be adding calendar code here as well, and tools/ was getting rather crowded, so it looks like time to move out a reasonably coherent sub-bundle of it all. Change-Id: I7e8030f38c31aa307f519dd918a43fc44baa6aa1 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-26 23:15:18 +0000