We Keep Coding

Getting Winter Time in C#

We are now in the summer time (UTC+01:00) but I need always winter time whereever I am.
For example now time is 08:05 and winter time is 07:05
I can find whether it is saving time or not by using this function
DateTime.Now.IsDaylightSavingTime()
and here is the delta (1 hour change)
TimeZoneInfo.Local.GetAdjustmentRules()[0].DaylightDelta;
so if I do something like that, is it correct?
var winterTime= DateTime.Now;
if (DateTime.Now.IsDaylightSavingTime())
{
winterTime = DateTime.Now.AddHours(-1 * delta.Hours);
}
or is there another way to do? (without using any 3rd solution)
Edit: The reason why I am asking this is that we are flashing a firmware to a nfc device and some dates in the devices should be in winter time. Thats why our tool should write winter time as paramter to the device.

In case DaylightDelta is not whole hours better use the TimeSpan directly. Also you need to find the rule in GetAdjustmentRules() that matches the current date. GetAdjustmentRules() returns both future and historical rules.
var now = DateTime.Today;
var rule = TimeZoneInfo.Local.GetAdjustmentRules().Where(x => now >= x.DateStart && now <= x.DateEnd).First();
winterTime = DateTime.Now - rule.DaylightDelta;

We are now in the summer time (UTC+01:00) but I need always winter time whereever I am.
...
... The reason why I am asking this is that we are flashing a firmware to a nfc device and some dates in the devices should be in winter time. Thats why our tool should write winter time as paramter to the device.
It sounds like you simply want to obtain the UTC time to set on the device. If so, just use DateTime.UtcNow. There is no need to concern yourself with time zones.
However, if you actually wanted to take the standard time (or winter time) for whatever local time zone you're in (that would seem to be a bit silly because that's not how local times work), but if you really are sure you want that, you can do it without querying adjustment rules. Instead, try this:
DateTime dt = DateTimeOffset.UtcNow.ToOffset(TimeZoneInfo.Local.BaseUtcOffset).DateTime;
This takes the current UTC time, applies the base offset of the local time zone, and then gives you back a DateTime with .Kind == DateTimeKind.Unspecified. The base offset is the offset from UTC that applies during standard time without any adjustment rules applied for DST.

Convert from local time to GMT (World Clock application using nodatime)

I am trying to program a world clock using Nodatime, and I have searched the web for samples on how to use the library and I have read the documentation, and it says that the class Instant is simply a number of "ticks" since some arbitrary epoch the Unix epoch, which corresponds to midnight on January 1st 1970 UTC. Well, I empirically guessed that if I used as an Instant a GMT value, then I could calculate with it the time values for each time zone (creating the world clock), and it worked. The problem that I have, is that I don't know a simple way to calculate the GMT time (or GMT instant) from the local time, my time zone is "America/Mexico_City", so my question is, is there a shortcut already defined in Nodatime to get the GMT time from a local time, or in the other hand, is there a simple way to implement the "Instant GetInstantGMT()" function (the function has to take in count the day light saving time issues)?

If you are just looking for the "current" instant, such represents now, then use:
Instant now = SystemClock.Instance.Now;
Calling it a "GMT instant" is redundant, since the Instant type is representing a universal moment in time without regard to time zone. It is (mostly) equivalent to UTC - which is essentially the same as GMT. In other words, you couldn't create an Instant that wasn't GMT.
Another way to think about an Instant is as if it were a DateTime whose .Kind property was permanently fixed to DateTimeKind.Utc and could not represent anything else.
Also, depending on exactly how your application is architected, you may find it useful to use the IClock interface instead:
IClock clock = SystemClock.Instance;
Instant now = clock.Now;
This would allow you to replace the system clock with a fake clock during unit testing.
Regarding how to go from a specific local time to an Instant, you would do something like this:
LocalDateTime ldt = new LocalDateTime(2013, 1, 1, 0, 0, 0);
DateTimeZone tz = DateTimeZoneProviders.Tzdb["America/Mexico_City"];
ZonedDateTime zdt = ldt.InZoneLeniently(tz);
Instant instant = zdt.ToInstant();
Note that I used InZoneLeniently in the conversion. This makes certain assumptions about how to translate from a local time that might be invalid or ambiguous due to daylight saving time. This might be acceptable, or you might instead prefer to use InZoneStrictly which will throw exceptions, or InZone which allows you to pass a resolver function so you can provide your own logic.

Is there any case where DateTimeOffset might not be reliable?

I understand that to refer a single point in time DateTimeOffset is better and more reliable way compared to DateTime as it replaces .Kind property by a more convenient thing that is the Offset to UTC.
Does this solve all the issues regarding to storing a single point in Date-Time or are there still some cases that I should be concerned about?
(If there are can you give me examples where DateTimeOffset can't be reliable?)
Thanks

Given a DateTimeOffset, there is never any confusion about what point in time that represents. So they are always reliable.
But there are some cases where a DateTimeOffset alone is still not sufficient. Here's an example of a common situation:
You are in New York, USA on March 10th 2013.
You find out about an event happening at 1:00 AM local time.
You record it as a DateTimeOffset with the value 2013-03-10T01:00:00-05:00.
Later, you find out that you were given incorrect information, the event actually occurred at 3:00 AM.
So you go to edit, and you change the value to 2013-03-10T03:00:00-05:00.
But this would be incorrect. On that particular day, daylight saving time starts, and so 3:00 AM is only one hour later than 1:00 AM. If you just advance the time, without considering that the offset may have changed, then you am referencing the wrong point in time.
It should have been 2013-03-10T03:00:00-04:00.
To overcome this situation, you must also know that the time was recorded in New York. You knew that in the first step, but then it was thrown out when you recorded it. Somewhere else in your application, you must hold on to this fact. Preferably, you would keep a time zone id, so that you could re-calculate the correct offset.
If using the TimeZoneInfo class in your application, then you would want to track the value of the .Id property, along with your DateTimeOffset. For New York, the time zone id would be "Eastern Standard Time". This is a bit confusing, because this same value is used regardless of whether DST is in effect or not. (There is no Windows time zone with an Id of "Eastern Daylight Time"). Also, there is no built-in class or struct that will pair a TimeZoneInfo with a DateTimeOffset. You have to do it yourself.
If you are using Noda Time (which I highly recommend). Then you can take advantage of the IANA time zone id of "America/New_York", and the ZonedDateTime object - which is designed for this exact situation.
You should also refer to DateTime vs DateTimeOffset. You should find the analogy there quite useful.
There are also some cases where DateTimeOffset is not appropriate. Maybe this one is obvious, but it's still worth mentioning.
When you are not refering to a single moment in time, but a relative point on the calendar.
This happens more often than you would think. For example:
In the United States, this year daylight saving time began on March 10th 2013 at 2:00 AM.
But it didn't happen at at the exact same moment. Each time zone has their own local 2:00 AM, so there are actually several different transition points on the instantaneous timeline.
(Aside, but worth mentioning, in Europe, DST ("Summer Time") happens all at once. The transition is based on the same UTC moment for Western, Central, and Eastern European time.)
There are other real-world examples where the same point on the calendar is not the same point in time, yet people tend to think of them as if they were.
Day boundaries ("today", "yesterday", "tomorrow")
Other whole named days ("this Wednesday", "last Friday")
Television Shows ("7PM Tuesday nights")
Telephone Calling Plans ("Free nights and weekends")
Countless others...
In Noda Time, you would use a LocalDateTime for these scenarios. Without Noda Time, you would use a DateTime with .Kind == Unspecified.

c# parse string (without timezone) to DateTime, taking DST into account

I've read many SO articles, but I don't seem to be able to find a good answer to the problem. Posted suggestions include functions that convert dates to and from strings more then once, concatenating bits on the end and it all just seems... messy
So to the problem:
We have servers around the world. All servers run in their own local time and keep logs with time entries that are local to the server. Some servers are in DST observing areas, others arent
Suppose I have these strings from a log: 2013-01-01 12:34:56, 2013-07-01 12:34:56
And I know that this server is in New York so it's UTC-5 or UTC-4 when DST is in operation
And I have the same strings from a log on a server in Hong Kong, where DST does not apply and the time zone is +8
What I'm after is a block of code where I can tell it:
Here is a string representing a time
Here is the timezone the string is from
Daylight Savings should apply if relevant
And the code will parse the string into a DateTimeOffset, where the offset is adjusted according to DST if the time being parsed is DST relevant
For example:
NY server log says "2013-01-01 ..." DST does NOT apply to this date in JANUARY so the date parsed should be:
12:34:56 in new york time, a.k.a 17:34:56 in UTC (because it's -5, no DST)
NY server log says "2013-07-01 ..." DST DOES apply to this date in june so the date parsed should be:
12:34:56 in new york time, a.k.a 16:34:56 in UTC (because it's -4, with the DST)
HK server, both date times parse to 04:34:56 UTC
Thanks guys

Firstly, I'd strongly recommend that you change the system to log in UTC everywhere. It'll make your life much simpler.
If you're really stuck with what you've got, you should use DateTime.TryParseExact with a DateTimeStyles of just 0 (the default). That will give you a value with a DateTimeKind of Unspecified, which is what you want. (It's not UTC, and it's not local to the machine doing the parsing.)
You can then use TimeZoneInfo.GetUtcOffset (with the right time zone for that log) to work out the offset, and create a DateTimeOffset from the two together.
As a completely biased aside, you could also change to use the Noda Time project I maintain, which will allow your code to be much simpler to understand :)

To get the UTC-times of the time logged in the different log files you will need to know the names of the local time zones. Then you can use the DateTimeOffset-struct TimeZoneInfo-class to calculate the UTC-times:
public DateTime ParseAsUtc(string logDate, string timezoneName)
{
var timeZone = TimeZoneInfo.FindSystemTimeZoneById(timezoneName);
var localDate = DateTime.Parse(logDate);
var offset = new DateTimeOffset(localDate, timeZone.GetUtcOffset(localDate));
return offset.ToUniversalTime().DateTime;
}
ParseAsUtc("2013-01-01 12:34:56", "Eastern Standard Time"); //01.01.2013 17:34:56
ParseAsUtc("2013-07-01 12:34:56", "Eastern Standard Time"); //01.07.2013 16:34:56
ParseAsUtc("2013-01-01 12:34:56", "China Standard Time"); //01.01.2013 04:34:56
ParseAsUtc("2013-01-01 12:34:56", "China Standard Time"); //01.07.2013 04:34:56

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.