Question

There is a relevant question about how ToUniversalTime works. But the relevant information about time conversions tells me there are relevant databases for time conversion in the past. My question is how can ToUniversalTime forecast and knows when will be the DST change in 2070 for example?

Was it helpful?

Solution

My question is how can ToUniversalTime forecast and knows when will be the DST change in 2070 for example?

It can't. It doesn't have any special insight into the future of what the governments of our world will decide to do with their time zones.

Any local time in the world is decided upon by the time zone rules that each locality sets by it's own standards. These change all the time for various reasons, either practical, political, or religious. There is no all-encompassing international governing body for this, nor are there any rules that they have to play by.

In practice, most governments tend to give some notice when making these changes. Typically they are at least a year out. For example, the USA announced in 2005 that changes would go into effect in 2007.

But that is not always the case. For example, in Egypt in 2011, daylight saving time was cancelled just 9 days before it was scheduled to go into effect.

All of these changes are tracked and captured by the two common time zone databases that we use in computing. You can read about these in the timezone tag wiki. Short-notice changes means everyone has to scramble to get updates out in a hurry, or risk their data being inaccurate.

So getting back to the heart of your question - when scheduling a future event, you need to know what the intended context is. If it's given to you in UTC, then you can know definitively what moment in time it is going to occur (ignoring leap seconds). But most of the time you are given a local time and time zone. You have to keep both of those values if it's a future date. You can't predict a future UTC conversion without risk that it might change.

Only once the date has passed are you ensured of the stability in a conversion. But then how do you schedule anything to actually trigger an event in your code? Well, one approach is to not try to do the conversion until you are closer to the approximate event time. Perhaps a one-week window is acceptable. Another approach is to convert everything right away, but hold on to the original data. Any time you get updated time zone information you can re-computed the conversion. Heck, you could recompute the conversion any time you want just to be on the safe side. It just depends on your application requirements.

As an aside, since this is a .NET/C# question and you said you're in Turkey, I highly suggest you consider using Noda Time and the Europe/Istanbul IANA time zone. This is just an example:

LocalDateTime ldt = new LocalDateTime(2013, 09, 17, 0, 0);
DateTimeZone tz = DateTimeZoneProviders.Tzdb["Europe/Istanbul"];
ZonedDateTime zdt = ldt.InZoneLeniently(tz);
Instant utc = zdt.ToInstant();
Debug.WriteLine(utc);             // 2013-09-16T21:00:00Z

If you are interested in how much the TZDB knows about time changes in Turkey, look here. By comparison, if you look in your Windows registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Turkey Standard Time\Dynamic DST, you will see that Windows only knows about changes in Turkey since 2010.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top