Overall, this looks great. I would like more clarity on timezone
specifications. Is the timezone argument to make-timestamp a timezone
object, or an Olson string or an implementation-dependent string? I hope
we can rule this last one out immediately, because it will result in
non-portable  (and unmaintainable) software. On this latter, British
Columbia was on PST until this spring. and would have gone to PDT but
for an act of the provincial legislature that eliminated the “fall back”
in November, resulting in us now being on PT. By contrast, using the
string "America/Vancouver" would work all the time.

According to 5 minutes of research, there is an unambiguous mapping from
Olson designators to Windows IDs (though not the reverse, as Olson is
more granular). Accordingly, a Windows implementation of this SRFI
should be required to employ this mapping. I do not know how this would
work on zOS, though.

I'm not sure that anything in the SRFI needs to be changed, but
clarifications would help.

-- vincent