"Pete McBreen, McBreen.Consulting" <mcbreenp / cadvision.com> writes:

> Overall I'd say that this behavior matches the least surprise
> feature, since Time.local(2000, 5, 1, 0, 0) will occur at Midnight
> local time on the 1st May, but when seen from November that time is
> not an integral number of 24 hour units since the clocks are set back
> one hour in October.

Pete:

The other side of the POLS is consistency: on Unix boxes you get

    1.upto(12) { |m| puts Time.local(2000, m, 1, 0, 0, 0) }

     Sat Jan 01 00:00:00 CST 2000
     Tue Feb 01 00:00:00 CST 2000
     Wed Mar 01 00:00:00 CST 2000
     Sat Apr 01 00:00:00 CST 2000
     Mon May 01 00:00:00 CDT 2000
     Thu Jun 01 00:00:00 CDT 2000
     Sat Jul 01 00:00:00 CDT 2000
     Tue Aug 01 00:00:00 CDT 2000
     Fri Sep 01 00:00:00 CDT 2000
     Sun Oct 01 00:00:00 CDT 2000
     Wed Nov 01 00:00:00 CST 2000
     Fri Dec 01 00:00:00 CST 2000

Now if Windows users are expecting displayed timezone to remain
unchanged, then I'd certainly agree with you that that trumps
consistency with Unix. However, if instead it's just something they
could live with, then I'd argue we should strive for consistency and
map the timezone to daylight savings if applicable.

Having said all that, time calculations and I are old enemies, so I
may well have all this bass-ackwards.


Dave