I ask because if I run the following program with the SRFI
adapted to R6RS, I get that June 5, 7 was a Tuesday but the
calendar from "cal 7" tells me that it was a Sunday.
(import (rnrs)
(srfi time))
(define the-date
(make-date
1 ; nanosecond
2 ; second
3 ; minute
4 ; hour
5 ; day
6 ; month
7 ; year
(* 60 61)))
(display (date->string the-date "~a"))
(newline)
AFAICT the SRFI was not changed, only adapted for R6RS. The
port I used is at:
<https://code.launchpad.net/~ikarus-libraries-team/ikarus-libraries/srfi>
--
Marco Maggi
Addition: I get the same from Larceny REPL:
$ larceny -err5rs
> (import (rnrs))
> (import (srfi :19))
> (define a (make-date 1 2 3 4 5 6 7 8))
> (date->string a "~a")
"Tue"
--
Marco Maggi
For what it's worth:
> (date->string (make-date 1 2 3 4 5 6 7 (* 60 61)))
"Tue Jun 05 04:03:02+0101 7"
> (date->string (make-date 1 2 3 4 5 6 2007 (* 60 61)))
"Tue Jun 05 04:03:02+0101 2007"
(This is PLT scheme v4.1.3.6+, if it matters)
I wonder if "7" is being silently converted to "2007".
It looks to me like your SRFI-19 expression and cal disagree for most
dates prior to 1753.
I discovered this via manual binary search with the following helper
function:
(define (check y)
(system (string-append "cal " (number->string y)))
(date->string (make-date 1 2 3 4 5 6 y 8) "~a"))
If you do some googling on 1752 and cal, you may discover some
interesting things.
http://www.farid-hajji.net/fun/cj-cal91752.html
http://en.wikipedia.org/wiki/Cal_(Unix)
I'm no calendar expert, but I bet you can resolve your problem by
switching from Gregorian to Julian Day, which srfi-19 says it
supports.
I hope there weren't any takers on that bet; I'm now retracting it,
since I couldn't figure out how to resolve this within ten minutes of
looking at srfi-19.
I couldn't leave it alone.
I don't think srfi-19 can provide much help directly for this problem,
as the switch from Julian to Gregorian was not an atomic event across
the globe, despite what one might think from the output of cal alone.
Still, there are some reasonable formulas you can use to calculate
dates on the Julian calendar.
Using the formulas documented here:
http://www.tondering.dk/claus/cal/node3.html#SECTION00360000000000000000
I wrote the following code:
;; dow : Nat Nat Nat -> (list Nat Nat)
;; returns (j-d g-d) where j-d represents julian day of week & g-d
represents gregorian
(define (dow day month year)
(let* ((a (quotient (- 14 month) 12))
(y (- year a))
(m (+ month (* 12 a) -2))
(j-d (modulo (+ 5 day y (quotient y 4) (quotient (* 31 m)
12)) 7))
(g-d (modulo (+ day y (quotient y 4)
(- (quotient y 100)) (quotient y 400)
(quotient (* 31 m) 12))
7)))
(list j-d g-d)))
(define (dow->sym d)
(cadr (assoc d '((0 sun) (1 mon) (2 tues) (3 wed) (4 thur) (5 fri)
(6 sat)))))
With these in place, we can calculate:
> (map dow->sym (dow 6 1 2009))
(mon tues)
> (map dow->sym (dow 5 6 7))
(sun tues)
> (map dow->sym (dow 14 9 1752))
(mon thur)
> (map dow->sym (dow 2 9 1752))
(wed sat)
;; for significance of last two, google: cal 1752
You folks might consider to just read the manual page for cal.
Excerpt:
"the year must be fully specified: ``cal 89'' will not display a
calendar
for 1989. Two parameters denote the month and year; the month is
either
a number between 1 and 12, or a full or abbreviated name as
specified by
the current locale."
Yes. When I request "cal 7" I mean the year 7, when Jesus
Christ is officially supposed to have been 7 years old.
--
Marco Maggi
I appreciate your analysis and code. But it is not an
answer.
There are problems and formulas associated to calendar
computations. Fine. We know. What is the position of
SRFI-19? It is a defining document, so IMHO it should make
clear what are the expected results, so that one can test if
an implementation is actually returning the defined results.
For example, a set of tests with significant dates could
be assembled and used to state what are the results.
"cal" from util-linux returns results different from
SRFI-19; and it seems that:
http://www.timeanddate.com/calendar/index.html?year=7&country=9
agrees with "cal"; but then this:
http://5ko.free.fr/en/year.php?y=7&s=
agrees with SRFI-19. So is the current implementation
(which, being software, may have bugs in it) the
authoritative source of the position of SRFI-19?
--
Marco Maggi
It is the reference implementation provided by Will
Fitzgerald, the author of SRFI 19. As for whether
he really intended to use the Gregorian calendar
even for long-ago dates, please note the second
paragraph of the abstract for SRFI 19:
A date is a representation of a point in time in the
Gregorian calendar, a 24 hour clock (with nanosecond
precision) and a time zone offset from UTC....
SRFI 19 also provides operations for manipulating
Julian dates, but Gregorian is apparently the
default. I believe that explains the discrepancies
between the reference implementation for SRFI 19
and the results returned by cal.
Will
Got it. Thanks.
--
Marco Maggi