There's nothing in the hyperspec about that. How does encode-universal-time know that 23 means 2023 and not 1923? Edit: The hyperspec says:
A decoded time is an ordered series of nine values that, taken together, represent a point in calendar time (ignoring leap seconds)
...
...
Year
An integer indicating the year A.D. However, if this integer is between 0 and 99, the "obvious" year is used; more precisely, that year is assumed that is equal to the integer modulo 100 and within fifty years of the current year (inclusive backwards and exclusive forwards). Thus, in the year 1978, year 28 is 1928 but year 27 is 2027. (Functions that return time in this format always return a full year number.)
Edit: I think the different results have to do with timezones. According to the hyperspec for encode-universal-time:
If time-zone is supplied, no adjustment for daylight savings time is performed.
That implies that there is some adjustment if you don't supply a timezone? I tried suppling a timezone of 0, which I think is GMT:
The function
encode-universal-timedoesn't give me the same results as you. Your results (shown in the comments):My results (with SBCL 2.4.0):
And, I get yet a third result when I use an online lisp compiler:
I'm not sure why, but changing the year from 23 to 2023 produces the same results:
There's nothing in the hyperspec about that. How does
encode-universal-timeknow that 23 means 2023 and not 1923? Edit: The hyperspec says:Edit: I think the different results have to do with timezones. According to the hyperspec for
encode-universal-time:That implies that there is some adjustment if you don't supply a timezone? I tried suppling a timezone of 0, which I think is GMT:
With a timezone of 0, I got the same numbers using the online lisp interpreter.