You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because of the use of 'timeZone' instead of 'newValue' in the setter, setting the timeZone of a DateFormatter doesn't actually work. Instead, it winds up re-setting the old value, which happens to be whatever was originally set, usually what we get from copying the default down in CoreFoundation.
Also adds a unit test to help prevent breaks like this again.
(cherry picked from commit 9f3e050)
Fix Off-By-One Error With System TimeZone
This one is nasty, since it creates problems for DateFormatter, while appearing to behave correctly. (Mostly)
By copying 1 too many bytes, we wind up with the null terminator in the CFString. This breaks DateFormatter in an annoying way that the system TimeZone is always considered to be GMT by the formatter. You can ask for the zone’s abbreviation, and it will be correct. The name will appear to be correct, except the length is 1 longer than it should be. All sorts of fun. But the moment you ask DateFormatter to give you a string (or parse one), it assumes the TimeZone is GMT and ruins your day.
Included is a test case which can detect this. The downside is that it doesn’t detect the problem if GMT is already the current TimeZone. It is possible a second, more targeted test should also be added here?
This also breaks getting the description on the NSTimeZone/CFTimeZone, but not the TimeZone because of the wrapping at play, because of the terminator that gets inserted into the string description.
(cherry picked from commit 827e842)
Cleanup SystemTimeZone tests
Cleans up the DateFormatter test, improves the information about how it doesn’t catch issues when the system time zone is already GMT, and adds a more focused test for the SystemTimeZone name issue that can catch it when GMT is the system time zone.
(cherry picked from commit 2219bd1)
Make UTC Explicit in test_dateDifferenceComponents
The test assumes that it is running as GMT/UTC. Because of the TimeZone.current fixes, the test is no longer guaranteed to be using GMT/UTC, and will use the system TimeZone and breaks when in PDT for example. By making the UTC assumption explicit, we remove one more variable on this test.
(cherry picked from commit 5b1bfc9)
Disable test_expectedTimeZone Case 1
This is hitting an issue on GMT time zones where it shows up as UTC when formatted.
(cherry picked from commit e826252)
letdiff1= calendar.dateComponents([.month,.year,.day], from: date1, to: date2)
242
251
XCTAssertEqual(diff1.year,1)
243
252
XCTAssertEqual(diff1.month,5)
244
253
XCTAssertEqual(diff1.isLeapMonth,false)
@@ -257,35 +266,35 @@ class TestNSDateComponents: XCTestCase {
257
266
XCTAssertNil(diff1.calendar)
258
267
XCTAssertNil(diff1.timeZone)
259
268
260
-
letdiff2=Calendar.current.dateComponents([.weekOfMonth], from: date2, to: date1)
269
+
letdiff2=calendar.dateComponents([.weekOfMonth], from: date2, to: date1)
261
270
XCTAssertEqual(diff2.weekOfMonth,-76)
262
271
XCTAssertEqual(diff2.isLeapMonth,false)
263
272
264
-
letdiff3=Calendar.current.dateComponents([.weekday], from: date2, to: date1)
273
+
letdiff3=calendar.dateComponents([.weekday], from: date2, to: date1)
265
274
XCTAssertEqual(diff3.weekday,-536)
266
275
XCTAssertEqual(diff3.isLeapMonth,false)
267
276
268
-
letdiff4=Calendar.current.dateComponents([.weekday,.weekOfMonth], from: date1, to: date2)
277
+
letdiff4=calendar.dateComponents([.weekday,.weekOfMonth], from: date1, to: date2)
269
278
XCTAssertEqual(diff4.weekday,4)
270
279
XCTAssertEqual(diff4.weekOfMonth,76)
271
280
XCTAssertEqual(diff4.isLeapMonth,false)
272
281
273
-
letdiff5=Calendar.current.dateComponents([.weekday,.weekOfYear], from: date1, to: date2)
282
+
letdiff5=calendar.dateComponents([.weekday,.weekOfYear], from: date1, to: date2)
274
283
XCTAssertEqual(diff5.weekday,4)
275
284
XCTAssertEqual(diff5.weekOfYear,76)
276
285
XCTAssertEqual(diff5.isLeapMonth,false)
277
286
278
-
letdiff6=Calendar.current.dateComponents([.month,.weekOfMonth], from: date1, to: date2)
287
+
letdiff6=calendar.dateComponents([.month,.weekOfMonth], from: date1, to: date2)
279
288
XCTAssertEqual(diff6.month,17)
280
289
XCTAssertEqual(diff6.weekOfMonth,2)
281
290
XCTAssertEqual(diff6.isLeapMonth,false)
282
291
283
-
letdiff7=Calendar.current.dateComponents([.weekOfYear,.weekOfMonth], from: date2, to: date1)
292
+
letdiff7=calendar.dateComponents([.weekOfYear,.weekOfMonth], from: date2, to: date1)
284
293
XCTAssertEqual(diff7.weekOfYear,-76)
285
294
XCTAssertEqual(diff7.weekOfMonth,0)
286
295
XCTAssertEqual(diff7.isLeapMonth,false)
287
296
288
-
letdiff8=Calendar.current.dateComponents([.era,.quarter,.year,.month,.day,.hour,.minute,.second,.nanosecond,.calendar,.timeZone], from: date2, to: date3)
297
+
letdiff8=calendar.dateComponents([.era,.quarter,.year,.month,.day,.hour,.minute,.second,.nanosecond,.calendar,.timeZone], from: date2, to: date3)
289
298
XCTAssertEqual(diff8.era,0)
290
299
XCTAssertEqual(diff8.year,315)
291
300
XCTAssertEqual(diff8.quarter,0)
@@ -299,7 +308,7 @@ class TestNSDateComponents: XCTestCase {
299
308
XCTAssertNil(diff8.calendar)
300
309
XCTAssertNil(diff8.timeZone)
301
310
302
-
letdiff9=Calendar.current.dateComponents([.era,.quarter,.year,.month,.day,.hour,.minute,.second,.nanosecond,.calendar,.timeZone], from: date4, to: date3)
311
+
letdiff9=calendar.dateComponents([.era,.quarter,.year,.month,.day,.hour,.minute,.second,.nanosecond,.calendar,.timeZone], from: date4, to: date3)
0 commit comments