This question already has an answer here:
What is this about adjustment rules when converting DateTime to UTC?
(1 answer)
Closed 7 years ago.
From https://msdn.microsoft.com/en-us/library/bb397769(v=vs.110).aspx
The TimeZoneInfo.ConvertTimeToUtc(DateTime) method does not necessarily produce results that are identical to the TimeZone.ToUniversalTime and DateTime.ToUniversalTime methods. If the host system's local time zone includes multiple adjustment rules, TimeZoneInfo.ConvertTimeToUtc(DateTime) applies the appropriate rule to a particular date and time. The other two methods always apply the latest adjustment rule.
Please can someone explain this more clearly, preferably with examples?
"Multiple adjustment rules" applies to having different rules for different years. Pretty common, daylight savings time rules are political decisions that often change. The TimeZone class only applies the current rule, even to historical dates. TimeZoneInfo can know about rules that were in effect in the past.
This ultimately depends on a database that keeps track of those rules. You can have a look-see at it, fire up Regedit.exe on Windows and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones. The "Israel Standard Time" key is an interesting one to peek at, their rules constantly change. Note the listed years in the Dynamic DST key. Compare to the Wikipedia article about it and note that it isn't complete, you'll see the mayhem before 2004 missing. As noted in the article, Microsoft gave up on trying to keep it accurate for a while.
In general, a machine needs to have Windows Update enabled to reliably keep track of rule changes.
Related
I'm not sure whether this is an SO question but still would like to know the answer.
Wikipedia says there are about 40 time zones, but when I invoke the TimeZoneInfo.GetSystemTimeZones() method in c# it returns a list of 101 elements.
Is the wiki article outdated (though it "was last modified on 26 April 2012 at 05:11") or are there any additional time zones?
There's no one answer - it depends on what time zone database you're interested in. Using TimeZoneInfo.GetSystemTimeZones will use the Windows time zones... if you use tzdb you're likely to see a lot more.
(The current Noda Time version returns 575 time zone IDs, for example, although that includes Etc/GMT+9, Etc/GMT+10 etc.)
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Web service - current time zone for a city?
Just wondering whether there is a public web service (without reading from local machine time zone) that I could use to get the current date-time in that city using C#.
You can use GeoNames to get the time zone. From that and the current UTC time, you can work out the local time. (You can also download the GeoNames data to avoid having to make a remote call.)
Note that GeoNames uses the Olson time zone names - there are various mappings from those to Windows time zone names around on the net for use with TimeZoneInfo, or (plug) you could use Noda Time to perform the UTC to local time conversion. While there are aspects of Noda Time which are unfinished, that part should work fine.
GeoNames has one.
There would have to exist a way for a Computer to know where it was located.
Computers, by and large, have no idea where they are.
That said, you could write something into your code that could set/specify where it was, then go from there using UTC.
A commercial one
http://worldtimeengine.com/api
I have an asp.net + c# application that uses System.DateTime.now for logging working hours of employees. the application is online and recently I have users connecting to it from outside of my country.
I have a client that wants his employees working abroad to log their working hours according to their timezone.
All the dates and hours that are documented in the db are not in universal time so I don't want to try and change backwards everything to UTC (I also think that's not applicable).
I'm aware of ways to detect the user's timezone- js and geo-location. the thing is I don't trust the accuracy level of both. in conclusion I thought i'd let the admin define through an interface time-zones and the user will pick the one he wishes to use.
Is this a proper way? What is the best practice for this?
10q very much.
I think your approach of having an admin define the timezones for a group of users makes a lot of sense. You will quite often find that people have the wrong timezone defined on their desktop PCs, adding another complication. If you set it explicitly, you are safe.
I would urge you to use UTC in your database. If you start mixing DateTimes which are from different timezones in the same database this is going to come back to bite you!
Having the DateTimes stored in UTC is definitely a best practice in my book. It may be quite a bit of work to convert your existing data, but it's probably going to be worth it in the long term if you already have a few users in different time zones (today it's two, but soon it could be three, four....) It's also going to make it easier to avoid problems around things like daylight savings time conversions, especially if the groups are in regions where the start and end of daylight savings is different, which is the case between the US and UK (I have to deal with these DateTime issues in my system).
I would not rely on any automatic detection of a user's timezone when data is entered into your UI. The first thing I'd do is associate users in the database with a timezone property. It doesn't sound like your users are changing their timezones much, if ever.
It shouldn't be too difficult to associate locations with either users or groups of users if you're not already doing it. Just add the timezone information along with their location, and use that in your code when creating a DateTime object from the input from your. It means one more piece of data that someone will have to manage, but it's going to be less troublesome than trying to automatically detect the timezone through code.
It's going to be very easy to miss conversions now that you're adding a new time zone. I would recommend making sure all your DateTime logic is centralized (extension methods or a helper class, depending on your framework version). Keep all your conversions and string formatting in a single place and make sure all your code references it.
Good luck, and write lots of unit tests around your conversions.
This question already has answers here:
Getting system Timezones in different languages
(4 answers)
Closed 6 years ago.
Is there any windows API or language feature (C++,C#) to get the time, date and time zone name in localized format for different languages?
EDIT: In C# I can get the localized strings for date and time, but it seems TimeZoneInfo doesn't have localized strings. I also didn't find it in the registry. Most probably you need to translate timezone names for yourself.
// Localize date for french
DateTime d = new DateTime.Now;
Console.WriteLine(d.ToString("D", new CultureInfo("fr-FR")));
See the GetTimeFormat, GetDateFormat, and GetTimeZoneInformation functions. To get the localized name for the time zone, it seems like you might need to pull it out of the registry. See the documentation for the TIME_ZONE_INFORMATION structure.
Since at least XP SP3, the Win32 API GetTimeZoneInformation produces names which are localized. In fact, the reason I found this question was that I would like a way to force these strings into English because I'm putting them in a debugging log and I'd like to be able to understand them without becoming fluent in all the world's natural languages. :-)
boost date_time localizations to the rescue.
I am working in C#.net - .Net fx is 2.0 which doesnot support converting between different time zones. I have wrote a scheduler based on UTC but it is giving errors of 1 hour in the DTS periods for London. I need some solution so that I can gat the correct time in any timezone relative to UTC with correct DST adjustments.
Is changing to .NET 3.5 absolutely out of the question? It would make your life much, much easier. Otherwise, you're stuck with the plain TimeZone and DaylightSavings classes, as well as having to fetch the known timezones using P/Invoke.
William Stacey has a blog post with some code to do this - but I haven't tried it, so can't vouch for its accuracy. (In my experience he's usually pretty good though :) There are no doubt similar bits of code around if that one doesn't help you.
I believe that the API he's using doesn't have access to historical data, btw. In other words, it will assume that DST always kicks in on the first Sunday of October (or whatever the rule is) rather than knowing that the rule has changed over time. TimeZoneInfo in .NET 3.5 supports historical data where the OS does.