On Sat, Feb 11, 2012 at 06:00:42PM +0100, Nicolas Cellier wrote:
> 2012/2/11 Chris Muller <asqueaker at gmail.com>:
> >>> +1 again, I like DateAndTime>>midnight to use receiver offset, and
> >>> consequently asDate too, it's the least surprising...
> >>> Well, it won't perfectly handle those legal days when DST change and
> >>> which are not 24h long, but it's already better than what we have.
> >>>
> >>> Now, if you don't have a local zero offset, you'll get
> >>> (Date newDay: 10 month: 2 year: 2012) = Date today = false
> >
> > Mmm, neither expression on either side of the = sign specifies an
> > offset, so you should get true, not false. ?Indeed, I get true in my
> > image:
> >
> > DateAndTime localOffset ?"-0:06:00:00"
> >
> > (Date newDay: 11 month: 2 year: 2012) = Date today ?"true"
> >
> 
> Ah yes, you are right I missed the change of Timespan>>#current
> 
> So the feature is:
> 
> DateAndTime now asDate = Date today = DateAndTime localOffset isZero.
> 
> That's a thing to remember, previously all dates were created with
> same localOffset (at least at time of creation).
> I still think we need helper messages for conversions to different time zone
> (my previous proposition is weak because it does not account for DST,
> we should better refer to TimeZone rather than offset...).

Yes, the offset should always be obtained via "DateAndTime localTimeZone offset".
That way the offset value is always maintained in one place. If you
require proper handling of DST and multiple time zones, you can install
the Olsen time zone tables (package TimeZoneDatabase), which will dispatch
"DateAndTime localTimeZone offset" to calculate the offset using the actual
time zone tables.

Dave