[racket-dev] racket/date, SRFI-19, date construction

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 <asumu at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130111/648ad4ff/attachment-0001.html>