Trying to get friends with SRFI-19

[tomas]

Hi,

I'm trying to parse some stuff, part of which are date
strings of the form "20200106", i.e. "YYYYMMDD". Since
I don't trust my input too much (or rather, my understanding
of it), I'd like to get a slap when my assumptions fail.

So I'd like to validate the date string.

SRFI-19 seems to be my friend. After checking that
everything is numeric, I try (the example is the
sixth of January 2020, at noon):

  (make-date 0 0 0 12 06 01 2020 7200)
  => #<date nanosecond: 0 second: 0 minute: 0 hour: 12 day: 6 month: 1 year: 
2020 zone-offset: 7200>

So far so good. But if I try a bogus date (say, instead of
month 01 I pick 32):

  (make-date 0 0 0 12 06 32 2020 7200)
  => #<date nanosecond: 0 second: 0 minute: 0 hour: 12 day: 6 month: 1 year: 
2020 zone-offset: 7200>

Ahem. Make-date happily accepts a month 32. This was
some surprise for me :)

Next I tried converting the thing to a Julian day and
back. My idea was that the conversion would "normalize"
the date representation, and if `equal' yields #t, we
have a sensible date.

This fails because after the double-conversion, the
time zone offset has shifted from 7200 to 3600, and
the two dates aren't equal?:

  (define d (make-date 0 0 0 12 06 01 2020 7200)) ; as above
  d
  => <date nanosecond: 0 second: 0 minute: 0 hour: 12 day: 6 month: 1 year: 
2020 zone-offset: 7200>

  (julian-day->date (date->julian-day d))
  => #<date nanosecond: 0 second: 0 minute: 0 hour: 11 day: 6 month: 1 year: 
2020 zone-offset: 3600>

Obviously I am barking up the wrong tree (if it's
a tree at all).

Is there a canonical way to validate a date string?

Confused. Thanks for any hint.

Cheers
-- tomás

signature.asc
Description: Digital signature