A: 

I assume you are using the longitude to calculate the GMT offset, but it sounds like what you need to do is something like this.

  1. Use the Lat, Long to work out what country (Locale) the destination is
  2. Get the future date using that Locale, and look at its GMT offset including any DST offset (its been a while since I have looked at this is C# but I'm sure its pretty obvious).
  3. Once you know the GMT and DST offset for the Locale, it should be fairly simple to accomplish whatever you need to do.

Remember that DST is controlled by a country, often by legislation, and is subject to change. Most Date code libraries try to keep this information up to date, but it can change in the short term. For example: in 2000 NSW, in Australia, changed its DST to make the Olympics more accessible to US and European audiences.

Dunderklumpen
+1  A: 

Here's Microsoft's article on DateTime best practices in .NET, which covers localization with accounting for Daylight Savings Time.

In short, make sure you're using universal times and GMT offsets. The

DateTime.ToUniversalTime()

method will convert any existing DateTime object into a UTC-version. Remember that UTC offsets work based on longitude - the prime meridian is longitude zero so the time there is GMT offset = 0. For California your GMT offset is going to be minus 800.

Additionally you can always grab the browser's locale and determine the timezone based off of that too:

http://madskristensen.net/post/Get-language-and-country-from-a-browser-in-ASPNET.aspx

Aaronontheweb
A: 

I suspect this is going to be quite hard - I don't know of any service which converts latitude and longitude into a time zone name.

  • Knowing the standard offset and DST offset doesn't help, as you won't know when they apply.
  • Knowing just the country (or even country and language) doesn't help, as you won't know the region.
  • Even with the exact position, you'd have to have a pretty accurate service to map every possible point on earth to the correct time zone

You might be best off using some heuristics to guess which set of time zones are possible, and then ask the user which one it actually is. Currently your best bet is probably to use TimeZoneInfo: when Noda Time is ready for production use, that would be a better bet. (I hope - it's my project.)

Once you've got a TimeZoneInfo (or the Noda Time ITimeZone) the rest is relatively easy using DateTime or DateTimeOffset (or ZonedDateTime in Noda). It's getting the time zone correctly to start with which is tricky.

EDIT: I've just found this SO question which suggests that Geonames may be your friend. I wouldn't be surprised if that supplied you with an Olson time zone name though - so you'll either have to use a converter to work out the Windows time zone ID, or something similar. (Let me know if you're interested in using a pre-release of Noda; this bit of it is pretty stable AFAIK.)

Note that your question cannot be answered with certainty due to political changes. Sometimes governments will make changes to time zones with very little warning. A couple of years ago, Argentina gave 11 days notice that they weren't going to observe DST, for example. Also, political boundaries can move over time. Basically you've got to hope that doesn't happen.

Jon Skeet
We can get the time zone of a location using longitudefrom the xml we can get the timezone difference of a location. but we cant get the time zone for a future date is not possible using this dll. XmlDocument Xdoc = new XmlDocument();Xdoc.LoadXml(xml);DataSet ds=new DataSet();ds.ReadXml(new System.IO.StringReader(Xdoc.DocumentElement.OuterXml));DateTime dtLT = DateTime.Parse(ds.Tables[0].Rows[0]["time"].ToString());TimeSpan tF=dtT-date;date= date.Add(tF);
Ratheesh.S
@Ratheesh.S: If you can only get the current offset, that's not a time zone. I don't know whether the time zone itself *is* available via that API, but again I'd expect it to be an Olson name rather than a Windows one.
Jon Skeet
@ Jon Skeet : yes you are correct . we can only get the timezone difference form UTC. so we can manage to calculate the local time of a location. but cant calculate for a future date because of Day light saving problem
Ratheesh.S