Actually fix the strptime tests
This has been a complicated issue to fix for a number of reasons. The core of it is that the behavior is different between different versions of macOS, some of which set possible-but-incorrect values. This commit addresses the issue by always using our computation for tm_wday and tm_yday on macOS. As a side-effect, strptime format strings that specify %u and %j will no longer work on macOS.
This commit is contained in:
1 parent
476b36770d
commit
0c9eacedaa
3 files changed
+18
-3
No files matched your search
+3
-2
@@ -7,9 +7,10 @@
|
||||
|
||||
# Check day-of-week and day of year computations
|
||||
# (should trip an assert if this fails)
|
||||
last(range(365 * 199)|("1970-03-01T01:02:03Z"|strptime("%Y-%m-%dT%H:%M:%SZ")|mktime) + (86400 * .)|strftime("%Y-%m-%dT%H:%M:%SZ")|strptime("%Y-%m-%dT%H:%M:%SZ"))
|
||||
# This date range
|
||||
last(range(365 * 67)|("1970-03-01T01:02:03Z"|strptime("%Y-%m-%dT%H:%M:%SZ")|mktime) + (86400 * .)|strftime("%Y-%m-%dT%H:%M:%SZ")|strptime("%Y-%m-%dT%H:%M:%SZ"))
|
||||
null
|
||||
[2169,0,10,1,2,3,1,9]
|
||||
[2037,1,11,1,2,3,3,41]
|
||||
|
||||
# %e is not available on mingw/WIN32
|
||||
strftime("%A, %B %e, %Y")
|
||||
|
||||
Reference in new issue
Block a user