Bruce wrote:
Sure, hence my "easy to say after the fact" remark. Once you've got it
wrong, you're usually stuck with it.
But if that's the only problem, isn't it trivial for you to just ignore the
time part?
Per above, what's stopping you from doing that? All you need to do is force
the .Kind of the DateTime to UTC after reading it from the DB (it should be
Unknown initialy). It isn't UTC, but that doesn't matter -- what matters is
that no time zone offsets are applied.
You will not be able to reliably tell what the date was in any other time
zone (that's just not possible without the time), but a date is a date.
--
J.
Storing everything in UTC still would not solve my probems. It isn't a
viable option because we have to maintain backward compatability with
previous versions of the application.
>
viable option because we have to maintain backward compatability with
previous versions of the application.
>
wrong, you're usually stuck with it.
The real issue is that dates should be stored as dates, not as date
time, unless there is a specific need for both such as in a time stamp.
>
time, unless there is a specific need for both such as in a time stamp.
>
time part?
When a date is entered as 10/16/2008 it needs to be displayed as that
regardless of the time zone.
>
regardless of the time zone.
>
the .Kind of the DateTime to UTC after reading it from the DB (it should be
Unknown initialy). It isn't UTC, but that doesn't matter -- what matters is
that no time zone offsets are applied.
You will not be able to reliably tell what the date was in any other time
zone (that's just not possible without the time), but a date is a date.
--
J.