Re: [racket-dev] racket/date, SRFI-19, date construction
Pierpaolo Bernardi wrote: You may want to look instead at (the time related parts of) SOFA (www.iausofa.org). I have libtoolised SOFA: https://github.com/marcomaggi/atsofa http://code.google.com/p/libtoolisations/downloads/list but the single test file I have included fails!!! Or I am understanding nothing... which is also possible. According to calculators on the Net, the Julian day number for 2013/01/13 is 2456306; but the function iauCal2jd() gives me 2455939.5. Damn! Damn! Damn! Time to lunch. -- Marco Maggi _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket/date, SRFI-19, date construction
iauCal2jd gives 240.5 +56305.0 (=2456305.5) which is the correct answer (of course!) 2013/1/13, Marco Maggi marco.maggi-i...@poste.it: Pierpaolo Bernardi wrote: You may want to look instead at (the time related parts of) SOFA (www.iausofa.org). I have libtoolised SOFA: https://github.com/marcomaggi/atsofa http://code.google.com/p/libtoolisations/downloads/list but the single test file I have included fails!!! Or I am understanding nothing... which is also possible. According to calculators on the Net, the Julian day number for 2013/01/13 is 2456306; but the function iauCal2jd() gives me 2455939.5. Damn! Damn! Damn! Time to lunch. -- Marco Maggi -- Inviato dal mio dispositivo mobile _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket/date, SRFI-19, date construction
Pierpaolo Bernardi wrote: iauCal2jd gives 240.5 +56305.0 (=2456305.5) which is the correct answer (of course!) Yes, thanks (I still have 2012 in my fingers). I fixed this in the repository. -- Marco Maggi _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket/date, SRFI-19, date construction
Pierpaolo Bernardi wrote: You may want to look instead at (the time related parts of) SOFA (www.iausofa.org). For my needs, I'm working at an FFI interface to SOFA, which I'll release on planet when ready. Interesting. If you are developing this on a public repository I would like to follow it. -- Marco Maggi _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket/date, SRFI-19, date construction
Thanks for taking this on! Ditto! I'm very happy to have this long, long-term annoyance resolved. Thanks! John smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket/date, SRFI-19, date construction
FWIW I did some sort of port of SRFI/19 to Typed Racket. I recall doing something along the lines of bridging the impedance mismatch between Racket and the SRFI, but whatever it was, was minimal. I was in a hurry. If anyone is interested. - date.rkt was a standard TR require/typed wrapping of srfi-19 https://github.com/RayRacine/racketlib/blob/master/prelude/type/date.rkthttps://github.com/RayRacine/racketlib/blob/master/prelude/type/datetime.rkt - datetime.rkt was intended to be a reasonable update of srfi-19 as a standard TR module based on Racket idioms, native apis. I did just enough to get those functions I needed and that was it. One thing I do recall is the that Leap Second table in srfi-19 was somewhat out of date. https://github.com/RayRacine/racketlib/blob/master/prelude/type/datetime.rkt Ray On Fri, Jan 11, 2013 at 1: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
Re: [racket-dev] racket/date, SRFI-19, date construction
On Fri, Jan 11, 2013 at 7:04 PM, Asumu Takikawa as...@ccs.neu.edu wrote: Note: in the long run, it's probably best to have a comprehensive srfi/19 replacement in racket/date, Agreed. srfi/19 also has some serious flaws, which I have no time at the moment to delve into. The one merit it has, is that being an srfi is meant to be a portable specification. I suggest to disregard srfi/19 as a source of inspiration. You may want to look instead at (the time related parts of) SOFA (www.iausofa.org). For my needs, I'm working at an FFI interface to SOFA, which I'll release on planet when ready. Cheers P. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket/date, SRFI-19, date construction
On Jan 11, 2013, at 2:34 PM, John Clements wrote: You may want to look instead at (the time related parts of) SOFA (www.iausofa.org). For my needs, I'm working at an FFI interface to SOFA, which I'll release on planet when ready. I much prefer pure racket code to FFI stuff--fewer cross-platform issues, install issues, etc. With that said, it certainly looks like SOFA is the right source for standards and definitions. Can it be Racket-ized by an eager undergraduate? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [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 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
Re: [racket-dev] racket/date, SRFI-19, date construction
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). I've been confused by this in the past as well. 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
Re: [racket-dev] racket/date, SRFI-19, date construction
On 2013-01-11 15:39:08 -0600, Robby Findler wrote: 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. I wrote a patch to make both of these use the same structure, attached to the e-mail. It seems to pass all of the srfi-19 and date tests (with some tests changed where appropriate). Does it look alright? It turns out there was one (sort of) good reason for SRFI-19 to define its own struct type: it used mutation for several functions. Racket's date/date* are immutable. I just changed these to use functional update. Another thing: when a string is converted to a date, it's possible that the format string only has time-of-day but no date specification. Previously, this produced a srfi/19 date with '#t's but I've now defaulted it to the start day of the Unix epoch (arbitrarily). Cheers, Asumu From 9ab3a4d77ec1c16a9148690b85d6e7924aaf105d Mon Sep 17 00:00:00 2001 From: Asumu Takikawa as...@ccs.neu.edu Date: Fri, 11 Jan 2013 21:06:01 -0500 Subject: [PATCH] Make srfi/19 compatible with date* structs --- collects/srfi/19/time.rkt| 183 +++--- collects/tests/srfi/19/tests.rkt | 36 2 files changed, 109 insertions(+), 110 deletions(-) diff --git a/collects/srfi/19/time.rkt b/collects/srfi/19/time.rkt index bac5a33..54ce061 100644 --- a/collects/srfi/19/time.rkt +++ b/collects/srfi/19/time.rkt @@ -79,7 +79,6 @@ ;; Date object and accessors ;; date structure is provided by core Racket, we just extended tu support miliseconds: srfi:make-date srfi:date? - deserialize-info:tm:date-v0 date-nanosecond srfi:date-second srfi:date-minute srfi:date-hour srfi:date-day srfi:date-month srfi:date-year date-zone-offset ;; This are not part of the date structure (as they are in the original Racket's date) @@ -608,40 +607,24 @@ time-in) ;; -- Date Structures -(define-values (tm:date srfi:make-date srfi:date? tm:date-ref tm:date-set!) - (make-struct-type - 'tm:date #f 8 0 #f - (list (cons prop:serializable - (make-serialize-info -(lambda (d) - (vector (date-nanosecond d) - (srfi:date-second d) - (srfi:date-minute d) - (srfi:date-hour d) - (srfi:date-dayd) - (srfi:date-month d) - (srfi:date-year d) - (date-zone-offset d))) -#'deserialize-info:tm:date-v0 -#f -(or (current-load-relative-directory) -(current-directory) - (make-inspector) #f null)) -(define deserialize-info:tm:date-v0 - (make-deserialize-info - srfi:make-date - (lambda () - (let ([d0 (srfi:make-date #f #f #f #f #f #f #f #f)]) - (values d0 (lambda (d1) -(tm:set-date-nanosecond! d1 (date-nanosecond d0)) -(tm:set-date-second! d1 (srfi:date-second d0)) -(tm:set-date-minute! d1 (srfi:date-minute d0)) -(tm:set-date-hour!d1 (srfi:date-hour d0)) -(tm:set-date-day! d1 (srfi:date-dayd0)) -(tm:set-date-month! d1 (srfi:date-month d0)) -(tm:set-date-year!d1 (srfi:date-year d0)) -(tm:set-date-zone-offset! d1 (date-zone-offset d0 +;; These identifiers originally referred to a separate date type, +;; but they now use Racket's native date type +(define (srfi:make-date nanosecond second minute +hour day month +year zone-offset) + (date* second minute + hour day month + year + ;; compute derived fields + (tm:week-day day month year) + (tm:year-day day month year) + #f + zone-offset + nanosecond + )) + +(define srfi:date? date?) ;; Racket's date structure has the following: ;; * second : 0 to 61 (60 and 61 are for unusual leap-seconds) @@ -655,23 +638,14 @@ ;; * dst? : #t (daylight savings time) or #f ;; * time-zone-offset : the number of seconds east of GMT for this time zone (e.g., Pacific Standard Time is -28800), an exact integer 36 -(define (date-nanosecond d) (tm:date-ref d 0)) -(define (srfi:date-second d) (tm:date-ref d 1)) -(define (srfi:date-minute d) (tm:date-ref d 2)) -(define (srfi:date-hour d) (tm:date-ref d 3)) -(define (srfi:date-day d)(tm:date-ref d 4)) -(define (srfi:date-month d) (tm:date-ref d 5)) -(define (srfi:date-year d) (tm:date-ref d 6)) -(define (date-zone-offset d) (tm:date-ref d 7)) - -(define (tm:set-date-nanosecond! d ns) (tm:date-set! d 0 ns)) -(define (tm:set-date-second! d s)
Re: [racket-dev] racket/date, SRFI-19, date construction
On Fri, Jan 11, 2013 at 8:13 PM, Asumu Takikawa as...@ccs.neu.edu wrote: On 2013-01-11 15:39:08 -0600, Robby Findler wrote: 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. I wrote a patch to make both of these use the same structure, attached to the e-mail. It seems to pass all of the srfi-19 and date tests (with some tests changed where appropriate). Does it look alright? (The diff shows all of the tests changing). Are the tests for exported functions? If so, that sound bad. It turns out there was one (sort of) good reason for SRFI-19 to define its own struct type: it used mutation for several functions. Racket's date/date* are immutable. I just changed these to use functional update. Was the mutation exposed via the library? Another thing: when a string is converted to a date, it's possible that the format string only has time-of-day but no date specification. Previously, this produced a srfi/19 date with '#t's but I've now defaulted it to the start day of the Unix epoch (arbitrarily). That sounds like a backwards incompatible change (in that some programs that could use srfi/19 would get #f out of selectors that now get something else). Could a srfi/19 date be a union of two structs, where one represented a time only? Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket/date, SRFI-19, date construction
On 2013-01-11 20:35:50 -0600, Robby Findler wrote: (The diff shows all of the tests changing). Are the tests for exported functions? If so, that sound bad. Only a subset of the string-date tests should have changed in the diff (which is how it shows up in my mail reader). Was the mutation exposed via the library? No, it wasn't. That sounds like a backwards incompatible change (in that some programs that could use srfi/19 would get #f out of selectors that now get something else). Could a srfi/19 date be a union of two structs, where one represented a time only? Potentially yes, but then it wouldn't be a Racket date struct. Also, I think the implementation of srfi/19 was actually violating its documented interface by allowing booleans to show up in these fields. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket/date, SRFI-19, date construction
On Fri, Jan 11, 2013 at 8:40 PM, Asumu Takikawa as...@ccs.neu.edu wrote: On 2013-01-11 20:35:50 -0600, Robby Findler wrote: (The diff shows all of the tests changing). Are the tests for exported functions? If so, that sound bad. Only a subset of the string-date tests should have changed in the diff (which is how it shows up in my mail reader). Oh, I see. These tests all appear to be about the item below we're debating (right?). Was the mutation exposed via the library? No, it wasn't. That sounds like a backwards incompatible change (in that some programs that could use srfi/19 would get #f out of selectors that now get something else). Could a srfi/19 date be a union of two structs, where one represented a time only? Potentially yes, but then it wouldn't be a Racket date struct. Also, I think the implementation of srfi/19 was actually violating its documented interface by allowing booleans to show up in these fields. I think backwards compatibility here is probably more important than it producing a racket date. Is there some reason not to think so? I believe this library gets used a lot. Maybe the parsing function could accept keyword optional arguments to say which day to use if one isn't specified? And if a date isn't specified, you'd get back a srfi/19 time struct instead of a racket date struct in this case (but where the other srfi/19 accessors return '#t's when they get time structs). Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket/date, SRFI-19, date construction
I don't know how important this is, but ideally serialized old SRFI-19 dates should now deserialize as date*. I think that you can just restore the definition of deserialize-info:tm:date-v0 and change the second function (the cyclic value builder) to raise an error: (define deserialize-info:tm:date-v0 (make-deserialize-info srfi:make-date (lambda () (error 'deserialize-info:tm:date-v0 cycles not allowed and also restore the provide. Ryan On 01/11/2013 09:13 PM, Asumu Takikawa wrote: On 2013-01-11 15:39:08 -0600, Robby Findler wrote: 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. I wrote a patch to make both of these use the same structure, attached to the e-mail. It seems to pass all of the srfi-19 and date tests (with some tests changed where appropriate). Does it look alright? It turns out there was one (sort of) good reason for SRFI-19 to define its own struct type: it used mutation for several functions. Racket's date/date* are immutable. I just changed these to use functional update. Another thing: when a string is converted to a date, it's possible that the format string only has time-of-day but no date specification. Previously, this produced a srfi/19 date with '#t's but I've now defaulted it to the start day of the Unix epoch (arbitrarily). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket/date, SRFI-19, date construction
Oh! Good point! On Fri, Jan 11, 2013 at 9:53 PM, Ryan Culpepper ry...@ccs.neu.edu wrote: I don't know how important this is, but ideally serialized old SRFI-19 dates should now deserialize as date*. I think that you can just restore the definition of deserialize-info:tm:date-v0 and change the second function (the cyclic value builder) to raise an error: (define deserialize-info:tm:date-v0 (make-deserialize-info srfi:make-date (lambda () (error 'deserialize-info:tm:date-v0 cycles not allowed and also restore the provide. Ryan On 01/11/2013 09:13 PM, Asumu Takikawa wrote: On 2013-01-11 15:39:08 -0600, Robby Findler wrote: 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. I wrote a patch to make both of these use the same structure, attached to the e-mail. It seems to pass all of the srfi-19 and date tests (with some tests changed where appropriate). Does it look alright? It turns out there was one (sort of) good reason for SRFI-19 to define its own struct type: it used mutation for several functions. Racket's date/date* are immutable. I just changed these to use functional update. Another thing: when a string is converted to a date, it's possible that the format string only has time-of-day but no date specification. Previously, this produced a srfi/19 date with '#t's but I've now defaulted it to the start day of the Unix epoch (arbitrarily). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/**dev http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/**dev http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket/date, SRFI-19, date construction
On 2013-01-11 20:58:02 -0600, Robby Findler wrote: I think backwards compatibility here is probably more important than it producing a racket date. Is there some reason not to think so? I believe this library gets used a lot. Ok, attached is a second attempt that will use a different struct type if `string-date` gets passed a format string that's missing day, month, or year. The `make-date` function will also construct one of these lax types if the day, month, or year fields is #t. These dates should work normally, except that racket/date won't like them. This doesn't attempt to preserve other laxness in srfi/19. For example, `make-date` previously would not do any error checking of its fields (so it won't error until an operation is used which cares about that field). It should also support deserialization like Ryan pointed out. Cheers, Asumu From 8855d390571eabbb9082516d2486301531c36dae Mon Sep 17 00:00:00 2001 From: Asumu Takikawa as...@ccs.neu.edu Date: Fri, 11 Jan 2013 21:06:01 -0500 Subject: [PATCH] Make srfi/19 compatible with date* structs --- collects/srfi/19/time.rkt| 229 ++ collects/tests/srfi/19/tests.rkt |8 ++ 2 files changed, 141 insertions(+), 96 deletions(-) diff --git a/collects/srfi/19/time.rkt b/collects/srfi/19/time.rkt index bac5a33..323d7d8 100644 --- a/collects/srfi/19/time.rkt +++ b/collects/srfi/19/time.rkt @@ -608,40 +608,46 @@ time-in) ;; -- Date Structures -(define-values (tm:date srfi:make-date srfi:date? tm:date-ref tm:date-set!) - (make-struct-type - 'tm:date #f 8 0 #f - (list (cons prop:serializable - (make-serialize-info -(lambda (d) - (vector (date-nanosecond d) - (srfi:date-second d) - (srfi:date-minute d) - (srfi:date-hour d) - (srfi:date-dayd) - (srfi:date-month d) - (srfi:date-year d) - (date-zone-offset d))) -#'deserialize-info:tm:date-v0 -#f -(or (current-load-relative-directory) -(current-directory) - (make-inspector) #f null)) -(define deserialize-info:tm:date-v0 - (make-deserialize-info - srfi:make-date - (lambda () - (let ([d0 (srfi:make-date #f #f #f #f #f #f #f #f)]) - (values d0 (lambda (d1) -(tm:set-date-nanosecond! d1 (date-nanosecond d0)) -(tm:set-date-second! d1 (srfi:date-second d0)) -(tm:set-date-minute! d1 (srfi:date-minute d0)) -(tm:set-date-hour!d1 (srfi:date-hour d0)) -(tm:set-date-day! d1 (srfi:date-dayd0)) -(tm:set-date-month! d1 (srfi:date-month d0)) -(tm:set-date-year!d1 (srfi:date-year d0)) -(tm:set-date-zone-offset! d1 (date-zone-offset d0 +;; These identifiers originally referred to a separate date type, +;; but they now use Racket's native date type +(define (srfi:make-date nanosecond second minute +hour day month +year zone-offset) + (if (or (eq? day #t) (eq? month #t) (eq? year #t)) + (srfi-19-date nanosecond second minute hour +day month year zone-offset) + (date* second minute hour + day month year + ;; compute derived fields + (tm:week-day day month year) + (tm:year-day day month year) + #f + zone-offset + nanosecond + ))) + +;; A struct type that emulates the old srfi/19 type +;; In particular, allows '#t' as day, month, year +(struct srfi-19-date (nanosecond second minute + hour day month + year zone-offset) +#:transparent) + +;; Convert srfi-19 date to date* +(define (srfi-19-date-date* date) + (srfi:make-date (srfi-19-date-nanosecond date) + (srfi-19-date-second date) + (srfi-19-date-minute date) + (srfi-19-date-hour date) + (srfi-19-date-day date) + (srfi-19-date-month date) + (srfi-19-date-year date) + (srfi-19-date-zone-offset date))) + +;; Predicate for dates +(define (srfi:date? d) + (or (srfi-19-date? d) (date? d))) ;; Racket's date structure has the following: ;; * second : 0 to 61 (60 and 61 are for unusual leap-seconds) @@ -655,23 +661,29 @@ ;; * dst? : #t (daylight savings time) or #f ;; * time-zone-offset : the number of seconds east of GMT for this time zone (e.g., Pacific Standard Time is -28800), an exact integer 36 -(define (date-nanosecond d) (tm:date-ref d 0)) -(define (srfi:date-second d) (tm:date-ref d 1)) -(define (srfi:date-minute d)
Re: [racket-dev] racket/date, SRFI-19, date construction
How about calling the new struct lax-date or something like that, using the word you're using below -- I'm not tied to that word, but something that explains more why it is there seems good. Also, I think the documentation needs to be updated to explain the relationship between the racket/date structs and the srfi-19 date structs. I'm less clear about the other laxness. One other possible thing to consider is that srfi:make-date could do all the same checking that date* does, but if any of it fails (perhaps catch the exn) it creates a lax date. That seems safest. And if we keep pushing a little more, then we can probably get all of the extra functionality of srfi/19 into racket/date and declare srfi/19 to be used only in old code and freeze it completely. Robby On Fri, Jan 11, 2013 at 10:57 PM, Asumu Takikawa as...@ccs.neu.edu wrote: On 2013-01-11 20:58:02 -0600, Robby Findler wrote: I think backwards compatibility here is probably more important than it producing a racket date. Is there some reason not to think so? I believe this library gets used a lot. Ok, attached is a second attempt that will use a different struct type if `string-date` gets passed a format string that's missing day, month, or year. The `make-date` function will also construct one of these lax types if the day, month, or year fields is #t. These dates should work normally, except that racket/date won't like them. This doesn't attempt to preserve other laxness in srfi/19. For example, `make-date` previously would not do any error checking of its fields (so it won't error until an operation is used which cares about that field). It should also support deserialization like Ryan pointed out. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket/date, SRFI-19, date construction
On 2013-01-11 23:08:30 -0600, Robby Findler wrote: How about calling the new struct lax-date or something like that, using the word you're using below -- I'm not tied to that word, but something that explains more why it is there seems good. That sounds good. Also, I think the documentation needs to be updated to explain the relationship between the racket/date structs and the srfi-19 date structs. I'm less clear about the other laxness. One other possible thing to consider is that srfi:make-date could do all the same checking that date* does, but if any of it fails (perhaps catch the exn) it creates a lax date. That seems safest. I thought about this, and the only objection that I had was that a contract error could now silently turn into a valid old srfi/19 style date object. Then again, this would only happen with the constructor exported from srfi/19, so maybe it's not a big deal. In any case, see attached patch for implementation (just catches the exception). Cheers, Asumu From 77287c4e948dabdb7c761af1b6f56d82cbc36adc Mon Sep 17 00:00:00 2001 From: Asumu Takikawa as...@ccs.neu.edu Date: Fri, 11 Jan 2013 21:06:01 -0500 Subject: [PATCH] Make srfi/19 compatible with date* structs --- collects/srfi/19/time.rkt| 226 ++ collects/tests/srfi/19/tests.rkt |8 ++ 2 files changed, 138 insertions(+), 96 deletions(-) diff --git a/collects/srfi/19/time.rkt b/collects/srfi/19/time.rkt index bac5a33..70617c7 100644 --- a/collects/srfi/19/time.rkt +++ b/collects/srfi/19/time.rkt @@ -608,40 +608,47 @@ time-in) ;; -- Date Structures -(define-values (tm:date srfi:make-date srfi:date? tm:date-ref tm:date-set!) - (make-struct-type - 'tm:date #f 8 0 #f - (list (cons prop:serializable - (make-serialize-info -(lambda (d) - (vector (date-nanosecond d) - (srfi:date-second d) - (srfi:date-minute d) - (srfi:date-hour d) - (srfi:date-dayd) - (srfi:date-month d) - (srfi:date-year d) - (date-zone-offset d))) -#'deserialize-info:tm:date-v0 -#f -(or (current-load-relative-directory) -(current-directory) - (make-inspector) #f null)) -(define deserialize-info:tm:date-v0 - (make-deserialize-info - srfi:make-date - (lambda () - (let ([d0 (srfi:make-date #f #f #f #f #f #f #f #f)]) - (values d0 (lambda (d1) -(tm:set-date-nanosecond! d1 (date-nanosecond d0)) -(tm:set-date-second! d1 (srfi:date-second d0)) -(tm:set-date-minute! d1 (srfi:date-minute d0)) -(tm:set-date-hour!d1 (srfi:date-hour d0)) -(tm:set-date-day! d1 (srfi:date-dayd0)) -(tm:set-date-month! d1 (srfi:date-month d0)) -(tm:set-date-year!d1 (srfi:date-year d0)) -(tm:set-date-zone-offset! d1 (date-zone-offset d0 +;; These identifiers originally referred to a separate date type, +;; but they now use Racket's native date type +(define (srfi:make-date nanosecond second minute +hour day month +year zone-offset) + (with-handlers ([exn:fail:contract? + (lambda (e) + (lax-date nanosecond second minute hour + day month year zone-offset))]) +(date* second minute hour + day month year + ;; compute derived fields + (tm:week-day day month year) + (tm:year-day day month year) + #f + zone-offset + nanosecond + ))) + +;; A struct type that emulates the old srfi/19 type +;; This is lax about its contents, unlike date* +(struct lax-date (nanosecond second minute + hour day month + year zone-offset) +#:transparent) + +;; Try to convert srfi-19 date to date* +(define (lax-date-date* date) + (srfi:make-date (lax-date-nanosecond date) + (lax-date-second date) + (lax-date-minute date) + (lax-date-hour date) + (lax-date-day date) + (lax-date-month date) + (lax-date-year date) + (lax-date-zone-offset date))) + +;; Predicate for dates +(define (srfi:date? d) + (or (lax-date? d) (date? d))) ;; Racket's date structure has the following: ;; * second : 0 to 61 (60 and 61 are for unusual leap-seconds) @@ -655,23 +662,29 @@ ;; * dst? : #t (daylight savings time) or #f ;; * time-zone-offset : the number of seconds east of GMT for this time zone (e.g., Pacific Standard Time is -28800), an exact integer 36
Re: [racket-dev] racket/date, SRFI-19, date construction
On Fri, Jan 11, 2013 at 11:29 PM, Asumu Takikawa as...@ccs.neu.edu wrote: On 2013-01-11 23:08:30 -0600, Robby Findler wrote: How about calling the new struct lax-date or something like that, using the word you're using below -- I'm not tied to that word, but something that explains more why it is there seems good. That sounds good. Also, I think the documentation needs to be updated to explain the relationship between the racket/date structs and the srfi-19 date structs. I'm less clear about the other laxness. One other possible thing to consider is that srfi:make-date could do all the same checking that date* does, but if any of it fails (perhaps catch the exn) it creates a lax date. That seems safest. I thought about this, and the only objection that I had was that a contract error could now silently turn into a valid old srfi/19 style date object. Then again, this would only happen with the constructor exported from srfi/19, so maybe it's not a big deal. yes, I think this is the right reasoning -- it isn't a big deal that srfi/19's constructor accepts everything (since it always has), but it is a big deal to preserve backwards compatibility. In any case, see attached patch for implementation (just catches the exception). I think it needs a few more test cases to test for the new racket/date functionality (ie that some calls return racket/date dates) and I think it makes sense to export the lax-date? predicate (perhaps from another library if you think that's important); that and the docs and I think it is ready to commit. Also, are there test cases that test the #t behavior for parsing time-only strings? If not, probably good to add those (and make sure those tests pass in the old version). Thanks for taking this on! Robby _ Racket Developers list: http://lists.racket-lang.org/dev
