b1379d34dd
It turns out glibc stops varying DST changes past where a 32-bit signed day-count from 1970 reaches (which, all things considered, can hardly be called a bug, for all that it's ...), at odds with QTZ's extrapolations from the current IANA DB rules. As the last date QDT can represent happens to be in the opposite side of everyone's DST from the one that leaves zones in, this lead to the 2038 local-time-type not reliably being useful for predicting the max-date behavior. So add a distant-future time-type that probes beyond glibc's cut-off, and have relevant tests check that instead of the 2038 one. Change-Id: If4e244d80fe2447da3bb9d5c406808c6c22c0a73 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
||
---|---|---|
.. | ||
animation | ||
global | ||
io | ||
ipc | ||
itemmodels | ||
kernel | ||
mimetypes | ||
platform | ||
plugin | ||
serialization | ||
text | ||
thread | ||
time | ||
tools | ||
CMakeLists.txt |