@autobusal/common 1.27.2 → 1.27.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +35 -0
- package/Calendar/utilities/settings.ts +35 -4
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,40 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 1.27.4
|
|
4
|
+
|
|
5
|
+
### Fixed
|
|
6
|
+
|
|
7
|
+
- **The calendar allowed a different set of days depending on the visitor's
|
|
8
|
+
timezone.** Day cells are built with `createDate`, which is `Date.UTC(...)`;
|
|
9
|
+
the selectable bounds were built with `new Date(y, m, d)` — *local*
|
|
10
|
+
midnight. Those are not the same instant, so the boundary day fell on
|
|
11
|
+
either side of the limit depending on where the visitor was sitting.
|
|
12
|
+
|
|
13
|
+
The consequence on the money path: **same-day departures were not
|
|
14
|
+
selectable west of Greenwich.** A visitor in New York or Los Angeles could
|
|
15
|
+
not pick today, because local midnight there is *after* the cell's UTC
|
|
16
|
+
midnight, so today's cell tested as below the minimum. Same-day selling was
|
|
17
|
+
deliberately enabled — this had been quietly undoing it for those visitors,
|
|
18
|
+
and it is invisible from Europe. Both sides are UTC now, so the comparison
|
|
19
|
+
is exact and identical everywhere.
|
|
20
|
+
|
|
21
|
+
Found while chasing an apparent off-by-one in the birth-date picker, which
|
|
22
|
+
turned out to be this skew wearing a different hat.
|
|
23
|
+
|
|
24
|
+
## 1.27.3
|
|
25
|
+
|
|
26
|
+
### Fixed
|
|
27
|
+
|
|
28
|
+
- **The birth-date picker offered today, which the API refuses.** obtapi
|
|
29
|
+
validates with `before:today`, so the calendar was letting you choose an
|
|
30
|
+
answer and then calling it wrong. It now stops at yesterday.
|
|
31
|
+
|
|
32
|
+
The year steps back too when yesterday fell in the previous one: the
|
|
33
|
+
maximum is built from `today.getFullYear() + limits.max.year`, so on 1
|
|
34
|
+
January a month/day of 31 December would otherwise have resolved to the
|
|
35
|
+
coming 31 December rather than the one just gone. Checked against 1
|
|
36
|
+
January, 1 March and a leap year.
|
|
37
|
+
|
|
3
38
|
## 1.27.2
|
|
4
39
|
|
|
5
40
|
### Fixed
|
|
@@ -82,8 +82,23 @@ export const getLimits = (type: ('picker' | 'dob' | 'date')): CalendarLimit => {
|
|
|
82
82
|
if (type === 'dob') {
|
|
83
83
|
limits.min.year = 100;
|
|
84
84
|
|
|
85
|
-
|
|
86
|
-
|
|
85
|
+
// Edited: Ferjolt Ozuni - Date: 2026-08-06
|
|
86
|
+
// Up to YESTERDAY, not today. obtapi validates a birth date with
|
|
87
|
+
// `before:today`, and somebody filling in this form was not born this
|
|
88
|
+
// morning - offering a day the API will refuse is a calendar that lets
|
|
89
|
+
// you choose an answer and then calls it wrong.
|
|
90
|
+
//
|
|
91
|
+
// The year is stepped back too when yesterday fell in the previous one,
|
|
92
|
+
// because max.time below is built from `today.getFullYear() +
|
|
93
|
+
// limits.max.year`: on 1 January, month 11 / day 31 without this would
|
|
94
|
+
// resolve to the coming 31 December rather than the one just gone.
|
|
95
|
+
const yesterday = new Date(today.getTime());
|
|
96
|
+
|
|
97
|
+
yesterday.setDate(yesterday.getDate() - 1);
|
|
98
|
+
|
|
99
|
+
limits.max.year = yesterday.getFullYear() - today.getFullYear();
|
|
100
|
+
limits.max.month = yesterday.getMonth();
|
|
101
|
+
limits.max.day = yesterday.getDate();
|
|
87
102
|
}
|
|
88
103
|
|
|
89
104
|
if (type === 'picker') {
|
|
@@ -104,9 +119,25 @@ export const getLimits = (type: ('picker' | 'dob' | 'date')): CalendarLimit => {
|
|
|
104
119
|
max: limits.max.year
|
|
105
120
|
},
|
|
106
121
|
|
|
122
|
+
/**
|
|
123
|
+
* Edited: Ferjolt Ozuni - Date: 2026-08-06
|
|
124
|
+
* BUILT IN UTC, because the day cells are.
|
|
125
|
+
*
|
|
126
|
+
* Days.tsx gets each cell's date from `createDate`, which is
|
|
127
|
+
* `Date.UTC(...)` - UTC midnight. These bounds were local midnight, and
|
|
128
|
+
* the two are not the same instant. East of Greenwich local midnight is
|
|
129
|
+
* EARLIER, so the boundary day sat just past the maximum and was greyed
|
|
130
|
+
* out; west of it the boundary day was included instead. The same
|
|
131
|
+
* calendar therefore allowed a different set of days depending on where
|
|
132
|
+
* the visitor was sitting, which is exactly the class of bug the
|
|
133
|
+
* departure floor above was already fixed for once.
|
|
134
|
+
*
|
|
135
|
+
* Same basis on both sides makes the comparison exact and the same
|
|
136
|
+
* everywhere.
|
|
137
|
+
*/
|
|
107
138
|
time: {
|
|
108
|
-
min:
|
|
109
|
-
max:
|
|
139
|
+
min: Date.UTC(today.getFullYear() - limits.min.year, limits.min.month, limits.min.day),
|
|
140
|
+
max: Date.UTC(today.getFullYear() + limits.max.year, limits.max.month, limits.max.day)
|
|
110
141
|
}
|
|
111
142
|
};
|
|
112
143
|
};
|