[racket-dev] `date*' (was: Re: Test results are slightly incomprehensible...)

At Wed, 28 Sep 2011 17:42:50 -0600, Matthew Flatt wrote:
> At Wed, 28 Sep 2011 18:12:34 -0500, Robby Findler wrote:
> > On Wed, Sep 28, 2011 at 6:04 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> > > At Wed, 28 Sep 2011 21:02:14 +0100, Paulo J. Matos wrote:
> > >> Errors were:
> > >> (Section (got expected (call)))
> > >> ((date) ((638931660) Error (find-seconds 0 1 2 1 4 1990)))
> > >
> > > After looking into this, I conclude that the test is faulty, but that
> > > it also highlights a bug/limitation on Windows:
> > >
> > >  * The test assumes that the current timezone had daylight saving time
> > >   starting at what would have been 2:00am on April 4, 1990.
> > >
> > >   The test will fail on your machine if your timezone is set to a
> > >   place with no or different DST rules (i.e., different than the
> > >   standard US timezones).

As a clarification, there are time zones in the US without daylight
saving, such as in Arizona.

> > Is there a way to check and see if the timezone is one of the US ones?
> 
> Not currently, but I guess I can add a way to get the current timezone
> name.

The time zone name turns out not to be enough information. For example,
the time zone name may be "MST" because you're in Utah in the winter,
or it may be because you're in Arizona at any time of the year. As
another example, I think "CST" can mean "China Standard Time" or
"Central Standard Time".


Still, having a way to the time zone name seems useful, and since I've
paged in all in, here's my plan:

 * Add a `date*' structure type as a subtype of `date' that adds
   `nanosecond' and `time-zone-name' fields. (The `nanosecond' field
   allows a `date* to hold all the fields of a SRFI-19 date.)

 * Change the `seconds->date' function to return a `date*'. It can also
   accept a real number instead of an exact integer, where any
   fractional part of the number is used in the `nanosecond' field of
   the result `date*'.


Meanwhile, I've changed the broken test to try a winter and summer date
in 2011; if the time zone name is "{ECMP}ST" for the winter date and
"{ECMP}DT" for the summer date, then the DST-related tests run. Using
the year 2011 avoids the Windows limitation (which is good to know
about, but we don't need to check every day that it's still there).