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:
William Langford committed 2017-11-29 20:47:56 -05:00
1 parent 476b36770d
commit 0c9eacedaa
3 files changed
+18 -3

No files matched your search

+3 -2
View File
@@ -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")