I think it would be great if you were to find backwards-compatible ways to bring these two a little bit closer. Making them use the same internal date struct, for example, would be a great thing.
And as you probably guessed, racket/date is the way it is for backwards compatibility reasons. I don't know how srfi/19 came to be, but it might just be because someone took the sample implementation from the srfi and stuck it into Racket. Robby On Fri, Jan 11, 2013 at 12:04 PM, Asumu Takikawa <as...@ccs.neu.edu> wrote: > Hi all, > > I had a few design questions about date types as used in the racket/date > and srfi/19 libraries. > > First, for some reason racket/date and srfi/19 use mutually incompatible > date representations and this is noted in the documentation (so it's > intentional). Is there a good reason for this? As far as I can tell, it > should be technically do-able to make srfi/19 use `date*` (for > nanoseconds) and thus be compatible with racket/date functions. > > Second, the date structure used by racket/date has some seemingly > extraneous fields. For example, `week-day` and `year-day` can be > calculated from the rest of the fields and aren't necessary (this is > annoying if you want to construct your own dates manually). > > Changing the structure is clearly a non-solution, but how about > exporting a different `make-date` constructor that makes `week-day`, > `year-day`, `dst?`, and `time-zone-offset` optional and default to > something sensible? > > Note: in the long run, it's probably best to have a comprehensive > srfi/19 replacement in racket/date, but in the meantime it'd be nice to > have a stopgap measure. > > Cheers, > Asumu > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev