We Keep Coding

Time zone conversion using time zone city coordinates and local time [duplicate]

This question already has answers here:
DateTime vs DateTimeOffset
(10 answers)
Closed 6 years ago.
I'm developing a scheduling web site where you can specify a date, time, time zone city. I want to save this in the backend in UTC time. So I have to convert it somehow on the server. I also want to provide the ability to convert to a different time zone on-the-fly.
In the Javascript I have a date/time value as well as a time zone city (from http://www.citytimezones.info which gives me geographical coordinates). I don't have the UTC time, only the time in the specified time zone.
Now I need to convert this future local time to UTC. Of course, it has to take into account the daylight savings time offset that will apply at that time.
Moreover I would like to convert to a different local time using a second time zone city.
I thought about using the Google Maps Time Zone API but this forces you to pass in the UTC time, which I don't have because I'm trying to calculate it.
In other words, ideally I need a system that will take these parameters:
Future time/date
Source time zone city coordinates
Destination time zone city coordinates (or null = UTC time)
and will return the converted time.
Any idea what I could do to make this happen?
This could be either a web service or a Windows C# library.

Split the problem into two parts:
Determining the time zone from location cooridnates
Converting time between time zones
You will find several ways to to do each.
For step 1, you mentioned Google Time Zone API, and CityTimeZones. Both of those are listed here, along with several other methods.
For step 2, your choices for .NET are primarily between Noda Time, or TimeZoneInfo. Martin gave several good examples of each in his answer.
Also, consider that scheduling is a more difficult scenario than most. You should read this post for more details.

You need a time zone database to perform the desired date and time conversions. Time zones are more complicated than simply being an offset because many time zones include daylight savings rules.
The .NET framework allows you to use the underlying Windows time zone database by using the TimeZoneInfo class. However, you can consider the Windows time zone database proprietary. IANA maintains the Time Zone Database (TZDB) which is described in Best Current Practice (BCP) 175.
The library Noda Time has support for TZDB and provided a local timestamp as a .NET DateTime and a time zone identifier you can compute the corresponding UTC timestamp:
var localDateTime = LocalDateTime.FromDateTime(dateTime);
var timeZoneId = "America/New_York"];
var timeZone = DateTimeZoneProviders.Tzdb[timeZoneId];
var zonedDateTime = timeZone.AtLeniently(localDateTime);
var utcDateTime = zonedDateTime.ToDateTimeUtc();
Notice that the local timestamp may be ambiguous or invalid. This happens during daylight savings transitions where the local clock is moved backwards (creates ambiguity) or forward (creates invalid times). The AtLeniently method makes some assumptions about how to handle ambiguity and invalid timestamps. This may be a source of errors in your application.
When you have a UTC timestamp and a time zone ID you can convert to local time in a similar fashion:
var instant = Instant.FromDateTimeUtc(utcDateTime);
var timeZone = DateTimeZoneProviders.Tzdb[timeZoneId];
var zonedDateTime = instant.InZone(timeZone);
var localDateTime = zonedDateTime.ToDateTimeUnspecified();
After taking a look at http://www.citytimezones.info/ it seems that the cities.txt contains the Windows time zone ID for each city in the last column. This makes it possible for you to lookup the Windows time zone ID based on the city.
You can then convert a local DateTime to UTC using this code:
var timeZoneId = "Eastern Standard Time";
var timeZoneInfo = TimeZoneInfo.FindSystemTimeZoneById(timeZoneId);
var utcDateTime = TimeZoneInfo.ConvertTimeToUtc(localDateTime, timeZoneInfo);
Notice that ConvertTimeToUtc will throw an ArgumentException if the local timestamp is ambiguous or invalid.
The reverse conversion from UTC to local time:
var localDateTime = TimeZoneInfo.ConvertTimeFromUtc(utcDateTime, timeZoneInfo);

UTC to local time conversion for previously saved datetimes if rules for timezone change

I'm storing a product in db. All dates (sql server datetime) are UTC and along with the dates I store the time zone id for that product. User enters the dates when product is available "from" and "until" in the listing.
So I do something like:
// Convert user's datetime to UTC
var userEnteredDateTime = DateTime.Parse("11/11/2014 9:00:00");
// TimeZoneInfo id will be stored along with the UTC datetime
var tz = TimeZoneInfo.FindSystemTimeZoneById("FLE Standard Time");
// following produces: 9/11/2014 7:00:00 AM (winter time - 1h back)
var utcDateTime = TimeZoneInfo.ConvertTimeToUtc(userEnteredDateTime, tz);
and save the record. Let's assume user did this on the 1st of August, while his time zone offset to UTC is still +03:00, nevertheless the saved date for the future listing has the correct +02:00 value because conversion took into consideration the "winter" time for that period.
Question is what datetime value will I get if I will attempt to convert that product's "from" and "until" date to product's local time zone on 11/11/2014 if, for example, due to some new rules the transition to winter time was abandoned, thus the time zone is still +03:00 instead of +02:00?
// Convert back
var userLocalTime = TimeZoneInfo.ConvertTimeFromUtc(utcDateTime, tz);
will I get 10AM or correct 9AM because OS/.NET patch will handle this?
Thank you!
P.S.: TimeZoneInfo has ToSerializedString() method, if I rather store this value instead of timezone id, will this guarantee that via UTC datetime + serialized timezoneinfo I will always be able to convert to the user's original datetime input?

In the scenario you describe, you would get 10:00 AM. The time zone conversion function would not have any idea that the value was originally entered as 9:00 AM, because you only saved the UTC time of 7:00 AM.
This illustrates one of the cases where the advice "always store UTC" is flawed. When you're working with future events, it doesn't always work. The problem is that governments change their mind about time zones often. Sometimes they give reasonable notice (ex. United States, 2007) but sometimes they don't (ex. Egypt, 2014).
When you made the original conversion from local time to UTC, you intentionally decided to trust that the time zone rules would not change. In other words, you decided that you would assign the event to the universal timeline based solely on the time zone rules as you knew them at that time.
The way to avoid this is simple: Future events should be scheduled in local time. Now, I don't mean "local to your computer", but rather "local to the user", so you will need to know the user's time zone, and you should also store the ID of the time zone somewhere.
You'll also need to decide what you want to do if the event falls into the spring-forward or fall-back transition for daylight saving time. This is especially important for recurrence patterns.
Ultimately though, you'll need to figure out when to run the event. Or in your case, you'll need to decide if the event has passed or not. There are a few different ways you can accomplish this:
Option 1
You can calculate the corresponding UTC value for each local time and keep it in a separate field.
On some cycle (daily, weekly, etc) you can recalculate upcoming UTC values from their local values and your current understanding of the time zone rules. Or, if you apply time zone updates manually, you can choose to recalculate everything at that time.
Option 2
You can store the values as a DateTimeOffset type instead of a DateTime. It will contain the original local time, and the offset that you calculated based on the time zone rules as you knew them at time of entry.
DateTimeOffset values can easily be coerced back to UTC, so they tend to work very well for this. You can read more in DateTime vs DateTimeOffset.
Just like in option 1, you would revisit the values periodically or after time zone data updates, and adjust the offsets to align with the new time zone data.
This is what I usually recommend, especially if you're using a database that has support for DateTimeOffset types, such as SQL Server or RavenDB.
Option 3
You can store the values as a local DateTime.
When querying, you would calculate the current time in the target time zone and compare against that value.
DateTime now = TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, targetTZ);
bool passed = now >= eventTime;
The down side of this option is that you may have to make lots queries if you have events in lots of different time zones.
You may also have issues with values close to the fall-back DST transition, so be careful if you use this approach.
I recommend against the idea of serializing the time zone itself. If the time zone has changed, then it has changed. Pretending that it hasn't isn't a good workaround.

Convert somebody's local time to the UTC time

i'm a little lost in the timezone :)
I have data stored with the time in UTC.
The server is in the Netherlands, so we live in utc+1 (now, with daylightsavingtime, in utc + 2)
Now a client says: give me the data from august 5th.
So i have to calculate the utc time from 'his time'.
For that i have to know:
what is your utc offset (we stored that in his profile, let's say utc -6)
are you in daylightsavingtime (because then we have to add +1 and make the utc offset -5)
Then my questions:
Can i ask the .Net framework: does country XX have daylightsavingtime?
Can i ask the .Net framework: is 08-05-2010T00:00:00 in country XXX daylightsavingtime at that moment?
i've been trying the .ToLocalTime(), but this only gives me the local time at the server, and that's not what i want, i want to calculate with the timezone of the user, and also with the fact that at that particular point in time, if he/she is in daylightsavingtime
I've also seen this VB example:
TimeZone As TimeZoneInfo = TimeZoneInfo.FindSystemTimeZoneById("W. Europe Standard Time")
Dim Dated As DateTime = TimeZoneInfo.ConvertTimeToUtc(TempDate, TimeZone)
but imho this doesn't take into account that the user in this timezone is or is not in a daylightsavingtime (dst) country.
For instance, one user in this timezone is in the netherlands having dst, and one other is in another country which has no dst.

You can't ask the framework about a particular country - but you can ask about a particular time zone.
TimeZoneInfo does take DST into account. (Heck, it wouldn't have the IsDaylightSavingTime method otherwise.) If you've got two users, one of whom is currently observing DST and the other of whom isn't, then they aren't in the same time zone.
If you could specify which locations you're talking about, I could try to find out which time zones are involved. (It's generally easier to find out the Olson names, but it shouldn't be impossible to find out the Windows IDs.)

TimeZone class has a method IsDaylightSavingTime that take a date as parameter
and return a boolean indicating if that date in in daylightsavingtime for that timezone.

I promote my comment to an answer.
It appears to be a complicate problem. Look at http://www.timeanddate.com/time/dst2010.html, there is a table of DST in various country of the world. You cannot get this with static code because DST change not only from country to country, but also from year to year.
I guess you have to maintain a table with DST information and get information from it.
Or you can query a webservice to get such infos.
Look at http://www.earthtools.org/webservices.htm#timezone for a webservice that you can query to get time in various country that take in account DST (it work only for Western Europe time zones).
Also look at http://www.geonames.org/export/web-services.html. You have to get your users geolocation to use these services.

Storing date/times as UTC in database

I am storing date/times in the database as UTC and computing them inside my application back to local time based on the specific timezone. Say for example I have the following date/time:
01/04/2010 00:00
Say it is for a country e.g. UK which observes DST (Daylight Savings Time) and at this particular time we are in daylight savings. When I convert this date to UTC and store it in the database it is actually stored as:
31/03/2010 23:00
As the date would be adjusted -1 hours for DST. This works fine when your observing DST at time of submission. However, what happens when the clock is adjusted back? When I pull that date from the database and convert it to local time that particular datetime would be seen as 31/03/2010 23:00 when in reality it was processed as 01/04/2010 00:00.
Correct me if I am wrong but isn't this a bit of a flaw when storing times as UTC?
Example of Timezone conversion
Basically what I am doing is storing the date/times of when information is being submitted to my system in order to allow users to do a range report. Here is how I am storing the date/times:
public DateTime LocalDateTime(string timeZoneId)
{
var tzi = TimeZoneInfo.FindSystemTimeZoneById(timeZoneId);
return TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, tzi).ToUniversalTime().ToLocalTime();
}
Storing as UTC:
var localDateTime = LocalDateTime("AUS Eastern Standard Time");
WriteToDB(localDateTime.ToUniversalTime());

You don't adjust the date for DST changes based on whether you're currently observing them - you adjust it based on whether DST is observed at the instant you're describing. So in the case of January, you wouldn't apply the adjustment.
There is a problem, however - some local times are ambiguous. For example, 1:30am on October 31st 2010 in the UK can either represent UTC 01:30 or UTC 02:30, because the clocks go back from 2am to 1am. You can get from any instant represented in UTC to the local time which would be displayed at that instant, but the operation isn't reversible.
Likewise it's very possible for you to have a local time which never occurs - 1:30am on March 28th 2010 didn't happen in the UK, for example - because at 1am the clocks jumped forward to 2am.
The long and the short of it is that if you're trying to represent an instant in time, you can use UTC and get an unambiguous representation. If you're trying to represent a time in a particular time zone, you'll need the time zone itself (e.g. Europe/London) and either the UTC representation of the instant or the local date and time with the offset at that particular time (to disambiguate around DST transitions). Another alternative is to only store UTC and the offset from it; that allows you to tell the local time at that instant, but it means you can't predict what the local time would be a minute later, as you don't really know the time zone. (This is what DateTimeOffset stores, basically.)
We're hoping to make this reasonably easy to handle in Noda Time, but you'll still need to be aware of it as a possibility.
EDIT:
The code you've shown is incorrect. Here's why. I've changed the structure of the code to make it easier to see, but you'll see it's performing the same calls.
var tzi = TimeZoneInfo.FindSystemTimeZoneById("AUS Eastern Standard Time");
var aussieTime = TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, tzi);
var serverLocalTime = aussieTime.ToLocalTime();
var utcTime = serverLocalTime.ToUniversalTime();
So, let's think about right now - which is 13:38 in my local time (UTC+1, in London), 12:38 UTC, 22:39 in Sydney.
Your code will give:
aussieTime = 22:39 (correct)
serverLocalTime = 23:39 (*not* correct)
utcTime = 22:39 (*not* correct)
You should not call ToLocalTime on the result of TimeZoneInfo.ConvertTimeFromUtc - it will assume that it's being called on a UTC DateTime (unless it's actually got a kind of DateTimeKind.Local, which it won't in this case).
So if you're accurately saving 22:39 in this case, you aren't accurately saving the current time in UTC.

It's good that you are attempting to store the dates and times as UTC. It is generally best and easiest to think of UTC as the actual date and time and local times are just pseudonyms for that. And UTC is absolutely critical if you need to do any math on the date/time values to get timespans. I generally manipulate dates internally as UTC, and only convert to local time when displaying the value to the user (if it's necessary).
The bug that you are experiencing is that you are incorrectly assigning the local time zone to the date/time values. In January in the UK it is incorrect to interpret a local time as being in a Summertime time zone. You should use the time zone that was in effect at the time and location that the time value represents.
Translating the time back for display depends entirely on the requirements of the system. You could either display the times as the user's local time or as the source time for the data. But either way, Daylight Saving/Summertime adjustments should be applied appropriately for the target time zone and time.

You could work around this by also storing the particular offset used when converting to UTC. In your example, you'd store the date as something like
31/12/2009 23:00 +0100
When displaying this to the user, you can use that same offset to convert, or their current local offset, as you choose.
This approach also comes with its own problems. Time is a messy thing.

The TimeZoneInfo.ConvertTimeFromUtc() method will solve your problem:
using System;
class Program {
static void Main(string[] args) {
DateTime dt1 = new DateTime(2009, 12, 31, 23, 0, 0, DateTimeKind.Utc);
TimeZoneInfo tz = TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time");
Console.WriteLine(TimeZoneInfo.ConvertTimeFromUtc(dt1, tz));
DateTime dt2 = new DateTime(2010, 4, 1, 23, 0, 0, DateTimeKind.Utc);
Console.WriteLine(TimeZoneInfo.ConvertTimeFromUtc(dt2, tz));
Console.ReadLine();
}
}
Output:
12/31/2009 11:00:00 PM
4/2/2010 12:00:00 AM
You'll need .NET 3.5 or better and run on an operating system that keeps historical daylight saving time changes (Vista, Win7 or Win2008).

Correct me if I am wrong but isn't
this a bit of a flaw when storing
times as UTC?
Yes it is. Also, days of the adjustment will have either 23 or 25 hours so the idiom of the prior day at the same time being local time - 24 hours is wrong 2 days a year.
The fix is picking one standard and sticking with it. Storing dates as UTC and displaying as local is pretty standard. Just don't use a shortcut of doing calculations local (+- somthing) = new time and you are OK.

This is a huge flaw but it isn't a flaw of storing times in UTC (because that is the only reasonable thing to do -- storing local times is always a disaster). This is a flaw is the concept of daylight savings time.
The real problem is that the time zone information changes. The DST rules are dynamic and historic. They time when DST starting in USA in 2010 is not the same when it started in 2000. Until recently Windows did not even contain this historic data, so it was essentially impossible to do things correctly. You had to use the tz database to get it right. Now I just googled it and it appears that .NET 3.5 and Vista (I assume Windows 2008 too) has done some improvement and the System.TimeZoneInfo actually handles historic data. Take a look at this.
But basically DST must go.

How to convert time between timezones (UTC to EDT)?

I need to have a common function to convert UTC time to EDT. I have a server in India. An application in it needs to use EDT time for all time purposes.
I am using .NET 3.5.
I found this on some other forum.
DateTime eastern = TimeZoneInfo.ConvertTimeBySystemTimeZoneId(
DateTime.UtcNow, "Eastern Standard Time");
When i tried with "Easten Daylight Time" I got an error.
"The time zone ID 'Eastern Daylight Time' was not found on the local computer".
Please help with this or any other solution.

Eastern Daylight Time isn't the name of a "full" time zone - it's "half" a time zone, effectively, always 4 hours behind UTC. (There may be proper terminology for this, but I'm not aware of it.)
Why would you want to use EDT for times which don't have daylight savings applied? If you want a custom time zone that always has the same offset to UTC, use TimeZoneInfo.CreateCustomTimeZone.
Note that if you use get the Eastern Standard timezone (TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time")) then that will still have daylight saving time applied appropriately (i.e. during summer).
For example:
TimeZoneInfo tzi = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time");
// Prints True
Console.WriteLine(tzi.IsDaylightSavingTime(new DateTime(2009, 6, 1)));
// Prints False
Console.WriteLine(tzi.IsDaylightSavingTime(new DateTime(2009, 1, 1)));

I would have said that you should use UTC for calculations of time periods, so that you avoid issues of daylight saving time and then use LocalTime for display only.
DateTime.ToLocalTime for UTC to whatever the local time zone is and then DateTime.ToUniversalTime to convert from local time to UTC.
Edit after comment 1
Do I take it then that you're after displaying a different timezone to that of the server?
If you're using web pages to access your server then use
HttpRequest.UserLanguages to help create a CultureInfo object and use that to parse your DateTime object.
Look here for a full explanation:Microsoft link on displaying local user time for web pages.
If you're using client-server architecture then if the LocalTime call is on the client side it will display the LocalTime for the client. You then convert it to UTC to send back to your server.
Either way your server doesn't need to know where the client is so if you have multiple clients in multiple timezones then all calculations will match. It will also allow you to show the times in any timezone that you wish by use of different Culture objects.
Edit 2 copied my second comment
You can get time data in UTC format from the server. Then you can convert it using DateTime.ToLocalTime or DateTime.ToUniversalTime as requried. If you're including dates as well and need to cope with say US MM/dd/yyyy and european dd/MM/yyyy formats the you can use CultureInfo class to parse the DateTime value accordingly. It sounds like more work than what you have at the moment, but it would mean that if you move your server again then you don't need to recode the DateTime handling.
A new point
Another point to look at is clock synchronisation between the server and the clients using NTP (Network Time Protocol) or SNTP (Simple Network Time Protocol) if it is accurate enough. I don't know what OS you are using but this is used by Windows Server time services to synchronise networks.

The cowboy method is to take the UTC time, subtract four hours' worth of seconds from it (the timezone offset), format it using a UTC formatting function, and slap a "EDT" label on it.
If you need to use Daylight Time sometimes and Standard Time other times, either make a lookup table of switchover dates, or use some calendar function.

TimeZoneInfo.ConvertTimeFromUtc will have correct offset depending on the DateTime you give it. For example:
3AM UTC/11PM ET (4 hour offset):
DateTime timeSummerET = TimeZoneInfo.ConvertTimeFromUtc(Convert.ToDateTime("08/01/2019 03:00:00"), zoneET);
3AM UTC/10PM ET (5 hour offset):
DateTime timeWinterET = TimeZoneInfo.ConvertTimeFromUtc(Convert.ToDateTime("12/01/2019 03:00:00"), zoneET);