Cor Ligthert said:
I find it not crazy it is everytime subtracting 1 hour in ticks from the
long in the datetime structure now.
But if you take something which is already UTC (because you've called
ToUniversalTime) then "converting" it into UTC should be a no-op -
which it is in .NET 2.0.
You British have to long been in the lucky situation that GMT was the same
as British Time but you have now Summertime too.
I find the dateTime pretty good. However you have to know what a datetime
represents
nowInUTC = Now.ToUniversalTime
And than is NowInUTC again a regular date for what the ToUniversalTime will
act on your system settings conform the method.
I am almost sure that you know that because otherwise you would not have
used now (lowercase) so consequent. I think that you thought that I would
not see that.
No, I didn't think that at all. The problem is that on .NET 1.1, a
DateTime had no idea whether it was a local time or a universal time -
so calling ToUniversalTime only made sense if the *caller* knew that it
was a local time to start with. It's better in .NET 2.0, in that it
knows the difference between local and UTC - but it only has the
concept of "local" rather than being for a particular TimeZone.
About making showable in a sufficient way the TimeZone tables with their
regions do we agree completely.
However I don't see the TimeZone in not any way as a part of the DateTime in
Net. It is additional information to use according the DateTime.
That's because the .NET libraries have been badly designed to be that
way. In Java there is a Calendar (which knows which TimeZone it's in,
along with things like what type of calendar it is (Gregorian etc)) and
a Date which is just a number of milliseconds since a particular UTC
time. The two are kept quite separate. .NET mixes them up by having
something which is essentially calendar-based, but with no idea of time
zone.
This is
another situation with a given date and time from by instance a SQL server
or an webpage. In that is the timezone very much needed. Unlucky enough it
is not given by both (in a standard way). In Net the datetime is only a
temporally value in a program and therefore it is not important where it is
created (as long as you can use it as an UTC time what is very simple
because the ToUniversalTime. In my idea should you never use this to create
another datetime).
Unfortunately it's very easy to get it wrong, and so silently - if you
happen to try to convert something to universal time twice, in .NET 1.1
you're pretty much bound to create a bug. Now, how many APIs for .NET
actually specify whether any DateTimes that you pass in or return are
in the local time or in UTC? Some of the framework ones do, but I
suspect most 3rd party libraries are much laxer. This is a fundamental
problem with the way DateTime was designed, and now of course it's too
late to fix it properly. There are half-fixes such as the local/UTC one
in 2.0, but it's still basically wrong.