Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

srfi time name of days

0 views
Skip to first unread message

Marco Maggi

unread,
Jan 6, 2009, 2:56:27 PM1/6/09
to

I apologise for my real ignorance on the matter; am I
supposed to get the same day name (Mon, Tue, ...) both from
SRFI-19 and the "cal" program from util-linux (version
2.12r)?

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

Marco Maggi

unread,
Jan 6, 2009, 3:05:32 PM1/6/09
to

"Marco Maggi" wrote:
> 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.

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

offby1

unread,
Jan 6, 2009, 3:32:01 PM1/6/09
to
On Jan 6, 11:56 am, Marco Maggi <ma...@maggi.it> wrote:
> (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)

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".

pnkf...@gmail.com

unread,
Jan 6, 2009, 6:22:25 PM1/6/09
to


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.

pnkf...@gmail.com

unread,
Jan 6, 2009, 6:32:25 PM1/6/09
to
On Jan 6, 6:22 pm, "pnkfe...@gmail.com" <pnkfe...@gmail.com> wrote:
> 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.


pnkf...@gmail.com

unread,
Jan 6, 2009, 11:02:31 PM1/6/09
to

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

whuk...@googlemail.com

unread,
Jan 7, 2009, 6:09:54 AM1/7/09
to

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."

Marco Maggi

unread,
Jan 7, 2009, 7:52:07 AM1/7/09
to

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

Marco Maggi

unread,
Jan 7, 2009, 8:15:35 AM1/7/09
to

"pnkfe...@gmail.com" wrote:
>> 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 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

William D Clinger

unread,
Jan 7, 2009, 9:15:21 AM1/7/09
to
Marco Maggi wrote:
> So is the current implementation
> (which, being software, may have bugs in it) the
> authoritative source of the position of SRFI-19?

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

Marco Maggi

unread,
Jan 7, 2009, 2:49:25 PM1/7/09
to

"William D Clinger" wrote:
>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

Got it. Thanks.
--
Marco Maggi

0 new messages