Daylight Saving Time with Old Dates

If you are sure of which zone the time was created, you can use this method:

public static DateTime ConvertToBrazilianTime(DateTime utc)
{
    return TimeZoneInfo.ConvertTimeBySystemTimeZoneId
        (utc, "E. South America Standard Time"); // Horário de Brasilia/BRA
}

This method receives a UTC date and converts it to the specified zone, it is smart enough to identify whether daylight saving time was in effect at the specified location and date.

Example:

// Data UTC 15/12/2012 10:00:00
DateTime dataUtc = MinhaQueryDoBanco.DataUtc;

// Converte de UTC para horário de Brasilia
// O método sabe que nessa data (15/12/2012) o horário de verão estava vigente
// então o datetime é convertido para 15/12/2012 08:00:00
// usando -02:00 ao invés de -03:00
DateTime dataLocal = ConvertToBrazilianTime(dataUtc);

See working in .NET Fiddle

Example 2 :

var date = new List<DateTime>();

// Criando Lista com range de datas.
for (int i = 0; i < 10000; i++)
{
    date.Add(DateTime.UtcNow.AddHours(-i));
}

foreach (var d in date)
{
    Console.WriteLine(ConvertToBrazilianTime(d));
} 

Result (note the difference on day 16 when DST takes effect):

See working in .NET Fiddle

There is confusion in the question and comments.

An hour as we say informally is a point in time. It exists in a unique way. Time is something astrophysical, has no spindle. For this reason the correct one is always to treat points in the time like UTC that is a universal time.

This site does this. And it's the right one. In general websites have display issues because they do not consider the spindle on the user's machine. No big problem, the time is right the presentation is not, so this site has chosen not to try to guess the spindle and uses UTC as a presentation. I know a lot of people find it absurd, but this has its advantages as well as disadvantages.

In an application for a lay user, it is ideal to present the time within the spindle. Presentation is something other than the timetable itself. Presentation is something visual, it is eventual.

If interest is the point in time it does not matter much how the time entered or how it will present, only universal time matters. So if someone logs in with 10:00 PM GMT-0200 or 9:00 PM GMT-0300 or 6:00 PM GMT-0600, and then it makes no difference whether it's summer time or not, it's fuse, everything will be 00: 00UTC.

If the user machine has a wrong spindle, it is the problem with that machine. The maximum that can be done is the system does not trust the operating system and ask the user to inform what is the spindle of it. Which is also unreliable, if you fool yourself even more. User confuses.

If something is set wrong on the machine it is his problem. You can create your own alternatives to try to help.

Now, if you do not want a point in time then you need to record the time in another way. If what you want is the visual timing of the moment the event occurred there record this time and not a point in time.

One way to do this is to save the time as local time . You know that field is a visual representation of the time and not the time itself.

You can also continue to record UTC and have another field that tells you what use is used, so when it comes to presenting, you know how to calculate the presentation time.

As this is not a point in time, it is not a quantification you can even write a string with the time, it's just a description.

If you have old schedules in UTC and want to know what their spindle is without having this recorded, I'm sorry, there's nothing to do, legacy error that will be charged for the rest of your life. It's like you use an integer and one day decide that you wanted the decimals of the recorded number.