Date fixup incomplete?

[nxg]

After constructing a date object, there's an assertion violation when formatting it.

(Is there a way of having scsh report its version (or indeed its build git checksum) internally? Perhaps a SCSH-VERSION constant, which reports "scsh 0.7 v 801a400ea1", or something like that)

Welcome to scsh 0.7
Type ,? for help.
> (define d (make-date 0 0 0 26 6 113))
; no values returned
> (format-date "~Y" d)

assertion-violation: argument of wrong type [string-length]
                     #f
1> ^D
> ^D
Exit Scheme 48 (y/n)? y

[roderyc]

Hey, thanks for all these issues; good to be reminded this is being used :). A constant with the git revision is a good idea, I'll look into adding that.

So, the problem is you're using format-date with a date made from make-date. If you don't give some of the optional arguments (specifically tzn and tzs in this case), some procedures in that api won't work. Does this work in scsh 0.6.7? I just realized I don't have a machine readily available that can install that version anymore.

Of course, giving a specific error for the missing data would be better behaviour. I might do that if there isn't an obvious way to go on without that data.

Relavent docs from 0.6.7:

 (make-date s min h mday mon y [tzn tzs summ? wday yday])     --->     date         (procedure) 

When making a date record, the last five elements of the record are optional, and default to #f, #f, #f, 0, and 0 respectively. This is useful when creating a date record to pass as an argument to time. Other procedures, however, may refuse to work with these incomplete date records.

[nxg]

It does work with 0.6.7:

Welcome to scsh 0.6.7 (R6RS)
Type ,? for help.
> (define d (make-date 0 0 0 26 6 113))
> (format-date "~Y" d)
"2013"
> (format-date "~Y-~m-~dT~H:~M:~S~Z" d)
"2013-07-26T00:00:00GMT"
> ^D

And though I'm aware of that qualification in the docs, I've never actually encountered the problem in practice.

The 0.6.7 docs mention a fill-in-date! function, though they note that it hasn't been completed yet.

It strikes me, though, that the wday and yday elements are redundant, in the sense that they can be straightforwardly calculated given the non-optional elements. Also the summ? element is redundant if tzs is specified and the IANA tz database is available.

If tzs isn't specified, then a default of zero seems reasonable; if someone doesn't specify this element, then that implies they don't care. Perhaps you could distinguish #f (meaning 'I haven't specified a timezone and I want any timezone functions I call to fail') from 0 (meaning 'I have specified timezone +0000, or else I know that I don't care and don't care about timezone-dependent functions possibly producing dubious results'). In that case, #f might be the best default.

I can potentially take a look at this part of the code; though I don't have many spare cycles at present, so I won't promise a timescale (also, I'd have to work out how to bend git to my will...)