On Wed, Sep 18, 2019 at 11:29 AM Alaric Snell-Pym <xxxxxx@snell-pym.org.uk> wrote:

Sure, but SQL-92 has a TIMESTAMP WITH TIME ZONE so it might be said that
"the SQL type system" has such a type (which most database backends
support), and it'd be nice to be able to use it directly most of the
time...

I agree.

By which I mean, as a "timestamp with time zone" thing exists in
SQL there should be a defined Scheme type for it that will work
correctly with any database that has a "timestamp with time zone" value
in it.

I have a pre-SRFI for exaclty that, but it's not very stable yet: <https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/TimeAdvancedCowan.md>. Pretty much every time I look at it, I end up changing it again. In addition, it only handles Gregorian time.

But what I do believe is that TIMESTAMP WITH TIME ZONE is the only self-interpreting SQL date-and-time type; if any other type is involved, a set of defaults (time or date as the case may be, as well as time zone) has to be applied to the value before Scheme gets a hold of it. There's also the problem that official SQL time zones are just offsets, but offsets are inherently inadequate (unless you're at sea); you really need IANA time zones.

John Cowan http://vrici.lojban.org/~cowan xxxxxx@ccil.org
After fixing the Y2K bug in an application:
WELCOME TO <censored>
DATE: MONDAK, JANUARK 1, 1900