I was working on the Gigasecond Anniversary exercise in the Common Lisp track. I wrote the solution that looked like it was making sense to me, but for some reason, hour values were off by 1 in one or another direction.
Example:
(GIGASECOND-ANNIVERSARY:FROM 1970 1 1 0 0 0)
evaluated to
(2001 9 9 2 46 40)
which is not
EQUAL
to
(2001 9 9 1 46 40)
I investigated a bit and found that sometimes decode-universal-time returned NIL for daylight savings and sometimes it returned T. Whether NIL or T was returned for daylight savings seemed to cause the hour shift to be +1 or -1, but only in some cases:
Daylight savings is T, so correct value is -1 from returned
(GIGASECOND-ANNIVERSARY:FROM 1970 1 1 0 0 0)
evaluated to
(2001 9 9 2 46 40 6 T)
which is not
EQUAL
to
(2001 9 9 1 46 40)
Daylight savings is NIL, so the correct value is +1 from returned
(GIGASECOND-ANNIVERSARY:FROM 2011 4 25 12 0 0)
evaluated to
(2043 1 1 12 46 40 3 NIL)
which is not
EQUAL
to
(2043 1 1 13 46 40)
Daylight savings is NIL, yet the values seem to be aligned:
(GIGASECOND-ANNIVERSARY:FROM 1900 1 1 0 0 0)
evaluated to
(1931 9 10 1 46 40 3 NIL)
which is not
EQUAL
to
(1931 9 10 1 46 40)
Does anyone know what could be causing this? I submitted the exercise (without the debug values visible in the above examples) once I got frustrated so that I could peek at how others handled this issue, but the exercise passed without changes.
I guess I should add that I’m on Windows 10 and I’m using SBCL 2.3.2, which is the latest available version on Windows, while Linux users are enjoying SBCL 2.3.5. Could this be it?