Repository navigation
Compute the Gregorian quarter from the month - #2364
alphasafal wants to merge 2 commits into
Conversation
|
@swift-ci test |
|
Thanks @itingliu for cross-checking, and thanks @niktishakov for closing #2319 in favour of this one. You found the same root cause first. On @parkera's question: as far as I can tell, quarter wasn't meant to come from the day of year. The quarter bounds were compared against a 1-based day-of-year as if it were 0-based, which has been off by one since #303. Deriving it from the month matches |
If you don't mind doing that, please do! Thanks and thank you @niktishakov too |
The quarter now comes from the month, so dayOfYear is only needed for .dayOfYear, .weekOfYear and .yearForWeekOfYear. Picked up from swiftlang#2319 at @itingliu's request.
|
Done in 78db4ca: |
|
Looks like some kind of infra issue on the tests. |
Compute the Gregorian quarter from the month.
Motivation:
_CalendarGregorian.dateComponentsderived.quarterfrom a 1-baseddayOfYearusing 0-based thresholds (< 90 / < 181 / < 273, and the leap-year variants). As a result the last day of Q1, Q2 and Q3 — March 31, June 30 and September 30 — was reported as the next quarter, every year.ordinality(of: .quarter, in: .year, for:)anddateInterval(of: .quarter, for:)already compute quarters from the month and disagree withdateComponentson these days.Fixes #2363
Modifications:
(month - 1) / 3 + 1, matchingordinalityanddateInterval.quarterAtQuarterBoundaries, which checks the first and last day of every quarter in a non-leap (2023) and a leap (2024) year.Result:
March 31, June 30 and September 30 report Q1, Q2 and Q3.
dateComponents,ordinalityanddateIntervalnow agree.Testing:
The new test fails on
main(6 failures) and passes with the fix on Linux; the rest of the suite passes on Linux, Windows, and the Android and Wasm builds.