Develop Reference

How can you determine the timezone offset needed for an arbitrary timezone with respect to daylight savings

I've seen solutions that make use of the current local timezone. What if I'm looking for the offset of a timezone which is not my own and is currently observing daylight savings time?
Edit:
I realize it is hard to infer exactly what I am asking for.
Currently when a user is set up in the system, they select a timezone. All of our data is converted to this timezone they selected (using the offset).
Example:
A user selects UTC-8, but then travels to somewhere that is UTC-6. We will display data and convert it based on the UTC-8 offset. The problem here being when daylight savings is applied to this timezone, it is effectively UTC-7. Based on the information available, I am able to get a TimeZoneInfo for UTC-8. I know I can extrapolate from the TimeZoneInfo.AdjustmentRule to determine if we are currently observing Daylight Savings, and what the delta is. I am curious if there was something in the framework I am missing that would handle this for me before re-inventing the wheel.
Note: This is a web application. The TimeZoneInfo is gathered on the server side, and pass down the User's offset so we can convert UTC to the user's selected timezone preference. I agree it would be easier if the user's browser client provided their system timezone, however it is not viable (due to business rules) to use the timezone of the browser, as the user wants to see the information based on the timezone they have selected.

You need to use the TimeZoneInfo class. I suspect your question is slightly misphrased. The offset is usually part of the name itself and on its own is not usually a very interesting fact. Its usefulness comes from what you then intend to infer from it.
You may be asking:
Given time X in timezone Y, what time is that in UTC
Given time X in timezone Y, what time is that in my local timezone
Given time X in my timezone, what local time will that be in timezone Y
Here is a starter which gives the first:
public static DateTime ConvertToUtc(DateTime timeOfInterest, string timezoneId)
{
TimeZoneInfo tz = TimeZoneInfo.FindSystemTimeZoneById(timezoneId);
if (tz.IsInvalidTime(timeOfInterest))
{
// Timezones with DST will be missing (usually) an hour one day a year, so some timeOfInterest
// values are not valid
throw new ArgumentOutOfRangeException($"{timeOfInterest} is not a valid time in {timezoneId} timezone");
}
return TimeZoneInfo.ConvertTimeToUtc(timeOfInterest, tz);
}
You could even do that as an extension method if you wanted.
For those other functions, see also:
tz.IsDaylightSavingTime()
tz.GetUtcOffset()
tz.SupportsDaylightSavingTime
TimeZoneInfo.ConvertTimeFromUtc()
TimeZoneInfo.ConvertTime()
Finally, be aware that these rules change all the time as different jurisdictions change their laws regarding the times that they observe. Make sure whatever system is performing these computations gets its windows updates.

Best practice for adding/subtracting from universal or local DateTime

I'm trying to add a wrapper around DateTime to include the time zone information. Here's what I have so far:
public struct DateTimeWithZone {
private readonly DateTime _utcDateTime;
private readonly TimeZoneInfo _timeZone;
public DateTimeWithZone(DateTime dateTime, TimeZoneInfo timeZone) {
_utcDateTime = TimeZoneInfo.ConvertTimeToUtc(DateTime.SpecifyKind(dateTime, DateTimeKind.Unspecified), timeZone);
_timeZone = timeZone;
}
public DateTime UniversalTime { get { return _utcDateTime; } }
public TimeZoneInfo TimeZone { get { return _timeZone; } }
public DateTime LocalTime { get { return TimeZoneInfo.ConvertTimeFromUtc(_utcDateTime, _timeZone); } }
public DateTimeWithZone AddDays(int numDays) {
return new DateTimeWithZone(TimeZoneInfo.ConvertTimeFromUtc(UniversalTime.AddDays(numDays), _timeZone), _timeZone);
}
public DateTimeWithZone AddDaysToLocal(int numDays) {
return new DateTimeWithZone(LocalTime.AddDays(numDays), _timeZone);
}
}
This has been adapted from an answer #Jon Skeet provided in an earlier question.
I am struggling with with adding/subtracting time due to problems with daylight saving time. According to the following it is best practice to add/subtract the universal time:
https://msdn.microsoft.com/en-us/library/ms973825.aspx#datetime_topic3b
The problem I have is that if I say:
var timeZone = TimeZoneInfo.FindSystemTimeZoneById("Romance Standard Time");
var date = new DateTimeWithZone(new DateTime(2003, 10, 26, 00, 00, 00), timeZone);
date.AddDays(1).LocalTime.ToString();
This will return 26/10/2003 23:00:00. As you can see the local time has lost an hour (due to daylight saving time ending) so if I was to display this, it would say it's the same day as the day it's just added a day to. However if i was to say:
date.AddDaysToLocal(1).LocalTime.ToString();
I would get back 27/10/2003 00:00:00 and the time is preserved. This looks correct to me but it goes against the best practice to add to the universal time.
I'd appreciate it if someone could help clarify what's the correct way to do this. Please note that I have looked at Noda Time and it's currently going to take too much work to convert to it, also I'd like a better understanding of the problem.

Both ways are correct (or incorrect) depending upon what you need to do.
I like to think of these as different types of computations:
Chronological computation.
Calendrical computation.
A chronological computation involves time arithmetic in units that are regular with respect to physical time. For example the addition of seconds, nanoseconds, hours or days.
A calendrical computation involves time arithmetic in units that humans find convenient, but which don't always have the same length of physical time. For example the addition of months or years (each of which have a varying number of days).
A calendrical computation is convenient when you want to add a coarse unit that does not necessarily have a fixed number of seconds in it, and yet you still want to preserve the finer field units in the date, such as days, hours, minutes and seconds.
In your local time computation, you add a day, and presuming a calendrical computation is what you intended, you preserve the local time of day, despite the fact that 1 day is not always 24 hours in the local calendar. Be aware that arithmetic in local time has the potential to result in a local time that has two mappings to UTC, or even zero mappings to UTC. So your code should be constructed such that you know this can never happen, or be able to detect when it does and react in whatever way is correct for your application (e.g. disambiguate an ambiguous mapping).
In your UTC time computation (a chronological computation), you always add 86400 seconds, and the local calendar can react however it may due to UTC offset changes (daylight saving related or otherwise). UTC offset changes can be as large as 24h, and so adding a chronological day may not even bump the local calendar day of the month by one. Chronological computations always have a result which has a unique UTC <-> local mapping (assuming the input has a unique mapping).
Both computations are useful. Both are commonly needed. Know which you need, and know how to use the API to compute whichever you need.

Just to add to Howard's great answer, understand that the "best practice" you refer to is about incrementing by an elapsed time. Indeed, if you wanted to add 24 hours, you'd do that in UTC and you'd find you'd end up on 23:00 due to there being an extra hour in that day.
I typically consider adding a day to be a calendrical computation (using Howard's terminology), and thus it doesn't matter how many hours there are on that day or not - you increment the day in local time.
You do then have to verify that the result is a valid time on that day, as it very well may have landed you on an invalid value, in the "gap" of a forward transition. You'll have to decide how to adjust. Likewise, when you convert to UTC, you should test for ambiguous time and adjust accordingly.
Understand that by not doing any adjusting on your own, you're relying on the default behavior of the TimeZoneInfo methods, which adjust backward during an ambiguous time (even though the usually desired behavior is to adjust forward), and that ConvertTimeFromUtc will throw an exception during an invalid time.
This is the reason why ZonedDateTime in Noda Time has the concept of "resolvers" to allow you to control this behavior more specifically. Your code is missing any similar concept.
I'll also add that while you say you've looked at Noda Time and it's too much work to convert to it - I'd encourage you to look again. One doesn't necessarily need to retrofit their entire application to use it. You can, but you can also just introduce it where it's needed. For example, you might want to use it internally in this DateTimeWithZone class, in order to force you down the right path.
One more thing - When you use SpecifyKind in your input, you're basically saying to ignore whatever the input kind is. Since you're designing general purpose code for reuse, you're inviting the potential for bugs. For example, I might pass in DateTime.UtcNow, and you're going to assume it's the timezone-based time. Noda Time avoids this problem by having separate types instead of a "kind". If you're going to continue to use DateTime, then you should evaluate the kind to apply an appropriate action. Just ignoring it is going to get you into trouble for sure.

How to handle timezone difference

I have my aplication which uses BST time zone(UTC+1) and another application where i am using the value from the above specified application . On my second server the timezone is UTC.
Because of this when i get value in a datetime property there is a diufference of one hour and because of that the value is going wrong.
I wont be able to adjust the timezone on both the servers . How can i convert the value to a BST time zone in my second application using .net.
public DateTime? EmploymentStartDate { get; set; }
This is my property in my model.
the value from my first server is 29/8/2001 00:00:00 when it comes to the second server where the timezone is UTC it is 28/9/2001 23:00:00 .

It's simple, you must consider all the DateTime always in UTC, so simply call ToUniversalTime() to convert every instance in UTC timezone:
DateTime dt = DateTime.Now;
dt.ToUniversalTime();

I agree with Daniel A. White. You should store everything as UTC and convert the date to local date on the client.
Look this https://msdn.microsoft.com/en-us/en-en/library/system.timezoneinfo.converttimefromutc(v=vs.100).aspx

private DateTime? _employmentStartDate;
public DateTime? EmploymentStartDate
{
get
{
return _employmentStartDate != null ? TimeZoneInfo.ConvertTimeFromUtc(_employmentStartDate.Value, TimeZoneInfo.Local) : new DateTime();
}
set
{
_employmentStartDate = TimeZoneInfo.ConvertTimeToUtc((DateTime)value);
}
}

Also consult this previous StackOverflow post:
Should MySQL have its timezone set to UTC?
This article (and the numerous other articles and web-pages that it links to) discusses MySQL, but the concerns and techniques are similar for any database and programming language.

While your (the OP's) question seems to be about how to convert time information between time zones, the discussion in the comments has grown hot on the subject of choosing a format for storage. First things first – to convert your UTC time to BST you can use TimeZoneInfo.ConvertTimeFromUtc. This method “converts a Coordinated Universal Time (UTC) to the time in a specified time zone.”
Here’s an example:
var bstZone = TimeZoneInfo.FindSystemTimeZoneById("GMT Daylight Time");
bstTime = TimeZoneInfo.ConvertTimeFromUtc(timeUtc, bstZone);
NB 1: If what you really want is local time on the server when executing, obviously you should rather use ToLocalTime(), and that will yield the same result if that local time happens to be BST (and the Kind property of the DateTime variable is not DateTimeKind.Local).
NB 2: To the best of my knowledge, the TimeZoneInfo class referrers to "British Summer Time" as "GMT Daylight Time", and I’m assuming that’s what you refer to as BST. But don’t take my word for it – you need to make sure yourself that you have the right time zone ID.
Now, about storing:
TL;DR
A time signature without time zone information is unreliable information. Given this premise, there is however no true “right or wrong” time zone to use for storing. While most people might argue that UTC is to be considered a best practice, first of all that information (that it's in UTC) should still be stored explicitly alongside the timestamp, and secondly, there may be practical reasons why another format is preferable in a specific scenario.
When performing arithmetic calculations on time values you should use universal time representations to avoid hiccups with regard to daylight saving practices and such.
Be weary of complications that might arise from serializing and de-serializing mechanisms making the wrong assumptions about the information you provide, e.g. System.XML.Serialization or a database engine.
Obviously, when presenting your time information (that is, when creating a string representation suitable for interpretation by humans), you should do so in whatever format the user should be expecting. Regardless of how you persist your values, conversions (with offset) may be necessary to do so.
Check out these links for more information:
Converting Times Between Time Zones
Coding Best Practices Using DateTime in the .NET Framework

How to change UTC timezone and get actual time?

The thing I am trying to achieve is, by using int values, change UTC datetime and receive time from different timezones.
Int values supposed to be:
0 = UTC+00:00
1 = UTC+01:00
...
By logic, it supposed to be something like:
int timezoneInt = 1;
var newDate = DateTime.UtcNow.AddMinutes(timezoneInt*60);
But the problem is that this not include summer/winter time.
For example:
My location is in UTC+02:00 and time is 09:20 AM. I need to get UTC+00:00 (which is equal to DateTime.UtcNow and supposed to be(?) 07:20 AM). Because of summer time, right now .UtcNow is 06:20 AM, so I can't just multiply 60 minutes by int value, I also need to include summer time factor somehow.
How I suposed to accomplish that, or what I am missing or understanded whong?
EDIT:
Was marked as dublicate. Well, here I don't see anything which will help change time by using int value as timezone.

Adjustments for daylight savings require an extensive timezone database which also records the dates and times when that zone changes to daylight savings, and what the new UTC offset is.
DST databases are not easy to build (or even use, in some cases) and must be manually researched and maintained as they are political, not technical - countries can change their daylight savings dates as they wish and so the database also needs to record historical dates.
The .NET Framework has a built-in TimeZoneInfo class (which obsoletes the TimeZone class) which makes use of the timezone database built-in to Windows or whatever the host OS is. Windows' timezone database uses full names to identify zones, whereas Linux and tzdb use IDs like America/New_York.
Note that generally you should never perform these calculations yourself as there are always numerous edge-cases to be aware of. Just use DateTimeOffset.
Also, there is not a 1:1 mapping between UTC offsets and timezones: different timezones share the same UTC offset but have different daylight savings rules (e.g. the British Time timezone uses UTC+0 as their normal UTC offset but UTC+1 in summer, but if you see "UTC+1" that could be either the British zone in summer or a West-African timezone such as Algeria's which is UTC+1, but does not use daylight savings at all.

Copied verbatim from the timezone tag wiki:
Time Zone != Offset
A time zone can not be represented solely by an offset from UTC. Many time zones have more than one offset due to daylight saving time (aka "summer time") rules. The dates that offsets change are also part of the rules for the time zone, as are any historical offset changes. Many software programs, libraries, and web services disregard this important detail, and erroneously call the standard or current offset the "zone". This can lead to confusion, and misuse of the data. Please use the correct terminology whenever possible.
An offset is just a number that represents how far a particular date/time value is ahead or behind UTC.
Most offsets are expressed in whole hours.
But there are many that are 30-minute offset.
And there are a few that are 45-minute offset.
A time zone contains much more:
A name or ID that can be used to identify the zone.
One or more offsets from UTC
The specific dates and times that the zone transitions between offsets.
Sometimes, a separate language-specific display name that can be presented to a user.
One can determine the correct offset, given a time zone and a datetime. But one cannot determine the correct time zone given just an offset.
You are asking how to ignore this fact and make it work anyway - which is not possible. You cannot use an integer offset and expect it to understand daylight saving time. Any solution that tries to defeat this will be taking a bias towards one particular set of daylight saving time rules, which are quite different from country to country.

How to convert Datetimes into UTC based timing values to compare timings- C#

I've string (variable is fileDate) with Date values in the following format:
2/12/2011 11:58 AM
Now I want to convert this to a date and then to UTC time based as I've problems in comparing dates in different machines, so *I always want to convert all strings (which are getting compared) to Utc_date values.*
I tried this code below but it did not work as I'm not able to convert the above string to Datetime based (as it does not have seconds).
DateTime date = Convert.ToDateTime(fileDate);
date = DateTime.SpecifyKind(date, DateTimeKind.Utc);
fileDate = date.ToString("MM/dd/yyyy hh:mm tt");
Above did not work showing FormatException.
Can you pl help?

To start with, I'd suggest using DateTime.ParseExact or TryParseExact - it's not clear to me whether your sample is meant to be December 2nd or February 12th. Specifying the format may well remove your FormatException.
The next problem is working out which time zone you want to convert it with - are you saying that 11:58 is a local time in some time zone, or it's already a UTC time?
If it's a local time in the time zone of the code which is running this, you can use DateTimeStyles.AssumeLocal | DateTimeStyles.AdjustToUniversal to do it as part of parsing.
If it's already a universal time, use DateTimeStyles.AssumeUniversal
If it's a local time in a different time zone, you'll need to use TimeZoneInfo to perform the conversion.
Also, if it's a local time you'll need to consider two corner cases (assuming you're using a time zone which observes daylight saving time):
A local time may be skipped due to DST transitions, when the clocks go forward. So if the clocks skip from 1am to 2am, then 1:30am doesn't exist at all.
A local time may be ambiguous due to DST transitions, when the clocks go back. So if the clocks go back from 2am to 1am, then 1:30am occurs twice at different UTC times - which occurrence are you interested in?
You should decide how you want to handle these cases, and make sure they're covered in your unit tests.
Another option is to use my date and time library, Noda Time, which separates the concepts of "local date/time" and "date/time in a particular time zone" (and others) more explicitly.

you should be using DateTime.ParseExact to get the value into a proper DateTime instance, and then you can use .ToUniversalTime() to get the UTC time (this would be with respect to the difference of time as in your server machine)

you can use :
DateTime.Now.ToUniversalTime();
i don't mean to say to you should use "DateTime.Now" but you get the point that as a part of the DateTime object you have a method to transform it to Universal time
http://msdn.microsoft.com/en-us/library/system.datetime.touniversaltime.aspx