[glib: 2/3] Fix the 6-days-until-the-end-of-the-month bug
- From: Emmanuele Bassi <ebassi src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [glib: 2/3] Fix the 6-days-until-the-end-of-the-month bug
- Date: Fri, 16 Oct 2020 13:47:23 +0000 (UTC)
commit da00779093f8c69b77b578795e8bec8e27f107d0
Author: Руслан Ижбулатов <lrn1986 gmail com>
Date: Mon Oct 5 16:53:47 2020 +0000
Fix the 6-days-until-the-end-of-the-month bug
The addition causes the date to shift
forward into 1st of the next month, because a 0-based offset
is compared to be "more than" the days in the month instead of "more than
or equal to".
This is triggered by corner-cases where transition date is 6 days
off the end of the month and our calculations put it at N+1th day of the
month (where N is the number of days in the month). The subtraction should
be triggered to move the date back a week, putting it 6 days off the end;
for example, October 25 for CET DST transition; but due to incorrect comparison
the date isn't shifted back, we add 31 days to October 1st and end up
at November 1st).
Fixes issue #2215.
glib/gtimezone.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
---
diff --git a/glib/gtimezone.c b/glib/gtimezone.c
index ef67ec50b..0de5c92a3 100644
--- a/glib/gtimezone.c
+++ b/glib/gtimezone.c
@@ -1041,7 +1041,11 @@ find_relative_date (TimeZoneDate *buffer)
/* week is 1 <= w <= 5, we need 0-based */
days = 7 * (buffer->week - 1) + wday - first_wday;
- while (days > days_in_month)
+ /* "days" is a 0-based offset from the 1st of the month.
+ * Adding days == days_in_month would bring us into the next month,
+ * hence the ">=" instead of just ">".
+ */
+ while (days >= days_in_month)
days -= 7;
g_date_add_days (&date, days);
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]