Re: UTC conversion from different time zones

Jon,

I can be wrong, but in my idea is the time in Net not real calendar based.
There is a calendar class which makes it possible to convert.

However the time in net starts at 01-01-01 00:00:00

The British Empire changed from Julian to Gregorian in 1753 (that was then
including the colonies in North America). AFAIK were they as normal the
last from the than existing European countries which did that change. This
means that every date before that time is incorrect. Therefore the startdate
for me in Net is a moment, which is relative in time.

However as I said, just as far as I know.

Cor



"Jon Skeet [C# MVP]" <skeet@xxxxxxxxx> schreef in bericht
news:MPG.1f121649c10ced4798d2a4@xxxxxxxxxxxxxxxxxxxxxxx
Cor Ligthert [MVP] <notmyfirstname@xxxxxxxxx> wrote:
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.

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too


.

Relevant Pages

  • Re: Web services and incorrect handling of time zones in DateTime
    ... You are not the first one writing this, I think that it is an error by design. ... when the SOAP message contains datetime like ... exactly the same time as previously, but in UTC), it becomes DateTime ... the UTC time should be converted to local time ...
    (microsoft.public.dotnet.general)
  • Re: System.TimeZone interface unusable?
    ... ToLocalTime must be "A DateTime instance whose value is the local time ... as the parameter states "a UTC time". ... serializer documentation is the only other place the Kind property is ...
    (microsoft.public.dotnet.framework)
  • Timezone and ISO8601 struggles with datetime and xml.utils.iso8601.parse
    ... I am trying to convert a local time into UTC ISO8601, then parse it ... How can I convert this into UTC? ... the date is converted into UTC on construction of the datetime object, ...
    (comp.lang.python)
  • Re: Time zones dates in vb.net 2005
    ... I have set the region on 1 computer to 'Perth Australia' and the other is on ... Store UTC only. ... know at which local time offset it has been stored. ... you can always use and calculate with the UTC datetime values. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Improving datetime
    ... Perhaps it might be wise to consider a 'calendar definition object' - I'll dub it a calinfo object for now - that allows third parties to develop a set of rules that define a) how to count in a calendar, and b) how to translate unambiguously from one calendar to another. ... a new 'superaware' datetime object represents a moment in time and would have: ... With time zones, because their offsets regularly swing back and forth, we have issues with illegal and ambiguous local times. ...
    (comp.lang.python)
Loading