UTC conversion from different time zones

[Guest]

I have a long list of events. I know where each event took place (globally)
and when (using the event’s local time). I want to do some comparisons
between these date/times. I thought I would convert them all to UTC and thus
get them all on a common time-line. But I can’t see how to do this. I can use
TimeZone.CurrentTimeZone to get the current TimeZone object and use its
ToUniversalTime method to convert dates that occurred in the current time
zone, but I can’t see how to get a TimeZone object for any of the other time
zones?

 

[Cor Ligthert [MVP]]

Dick,

I wished it was there, however it is probably impossible to do, timezone is
partialy declared by government, by instance India has its own timezone
which is UTC + 5:30 plus.

But even then it is difficult, beside that we have the Daylight saving time
(USA) or SummerTime (EU) or what ever, those starts and ends in the EU
completely at the same moments for the complete EU, but by instance the USA
which has an act for that, has that many irregulation on that: as well does
it often change..

http://en.wikipedia.org/wiki/Daylight_saving_time

To get universal time from a Net DateTime is however easy that is

DateTime.ToUniversalTime.

I hope this gives an idea,

Cor

 

[Jon Skeet [C# MVP]]

I wished it was there, however it is probably impossible to do, timezone is
partialy declared by government, by instance India has its own timezone
which is UTC + 5:30 plus.

It's feasible to do - Java does a reasonable job of it. .NET just has
pitiful support for other time zones. The operating system knows about
the, but there's no way (without using interop) of getting the list of
timezones. I believe there are freeware libraries available to do this,
but I haven't used any.

(Java libraries make dates/times a pain in other ways, but they at
least *allow* you to work with other timezones in a reasonable way.)

But even then it is difficult, beside that we have the Daylight saving time
(USA) or SummerTime (EU) or what ever, those starts and ends in the EU
completely at the same moments for the complete EU, but by instance the USA
which has an act for that, has that many irregulation on that: as well does
it often change..

Again, operating systems have to know about it anyway...

To get universal time from a Net DateTime is however easy that is

DateTime.ToUniversalTime.

That's fine so long as the DateTime represents the time in your local
timezone. It's a shame DateTime has little concept of which timezone
it's representing a date/time in. (.NET 2.0 is a little better than
..NET 1.1 in this, but not a lot.)

As an example of how broken this was in 1.1, try compiling the
following with the 1.1 compiler (so that it uses the 1.1 framework):

using System;

class Test
{
static void Main()
{
DateTime now = DateTime.Now;
for (int i=0; i < 5; i++)
{
Console.WriteLine (now);
now = now.ToUniversalTime();
}
}
}

The results right now on my box:
02/07/2006 14:30:17
02/07/2006 13:30:17
02/07/2006 12:30:17
02/07/2006 11:30:17
02/07/2006 10:30:17

Crazy, huh? (It makes sense when you realise how little idea DateTime
had of what was actually going on, but it still shows an oddity in the
framework.)

It's better in .NET 2.0 - after the first iteration the same time is
always returned, because it then "knows" that it's in UTC.

 

[Cor Ligthert [MVP]]

Jon,

I find it not crazy it is everytime subtracting 1 hour in ticks from the
long in the datetime structure now.

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.



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. 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).

Just my thought,

Cor

 

[Jon Skeet [C# MVP]]

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.

 

[Cor Ligthert [MVP]]

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]]

I can be wrong, but in my idea is the time in Net not real calendar based.

Well, it's certainly not "instant in time" based either - because that
would require knowing the timezone. Basically, it's not well specified
exactly what a particular DateTime really means.

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.

But what it's relative to depends on its use, which doesn't make it
terribly useful. I've written quite a few apps which require working
with this kind of information, and it's *always* a pain to work out
exactly what's required, whatever language you're using - but at least
Java has the right principles in its classes. With .NET 1.1, you don't
know what a partiucular DateTime is meant to be - UTC, local, or with
respect to some other timezone. .NET 2.0 is slightly better, but only
slightly IMO.

 

[Jeffrey Tan[MSFT]]

Hi Richard,

Thanks for your post!

Yes, I see your concern. TimeZone class does not expose an interface for
retrieving a specific timezone object instance.

After performing some search internally, I found that this is a known issue
in this version. Enumerating TimeZone's is actually quite difficult because
of naming issues and areas that use non-hour offsets from UTC. Our product
team is planning on adding this functionality in the next version, such as
adding a method named GetTimeZones(). For now, .Net FCL only support UTC
and the CurrentTimeZone.

Thanks for your understanding.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.