I would have proposed to create (Date newDay: 5 month: 2 year: 2012)
with a 0 offset because it has nothing to do with local time zone,
unlike Date today...
However, this might be a false good idea, because if we want this feature:
    (Date newDay: 5 month: 2 year: 2012) = Date today.
then we need that both dates be in same time zone...

There are several solutions possible then:
1) let the day start at local time zone, but use correct DST
information at this date
2) erase offset information

Unless we override Date>>=, but then Date wouldn't be a well behaved Timespan.
So this leads to solution 3), create a new class unrelated to Timespan...

Or solution 4) create explicit localized and unlocalized messages (or
find better names)...
For example Date today unlocalized

Nicolas.

2012/2/4 Jon Hylands <jon at huv.com>:
> On Sat, Feb 4, 2012 at 12:43 AM, David T. Lewis <lewis at mail.msen.com> wrote:
>
>>
>> I'm struggling to understand why "Date today" should be a TimeSpan that
>> begins at some time other than midnight in my local time zone. The date
>> that I think of as "4 February 2012" began about 20 minutes ago here in
>> Detroit, but in London and Paris it is old news.
>
>
> David,
>
> The issue that I'm having is this:
>
> When I evaluate and store this object today: (Date newDay: 1 month: 1 year:
> 2012), and then six months later I evaluate exactly the same expression,
> because I live in a country where daylight savings is applied, those two
> objects will not be equal.
>
> I can't think of a single logical reason why it should work that way. When I
> create a date (any date), it sets the timezone of the date to be whatever
> current timezone I happen to be in. That makes Date completely unusable as a
> historical indexing object.
>
> - Jon
>
>
>
>