EnterpriseLibrary.Logging writes logs with 1 hour difference

we encounter a weird problem with logging. We are using Microsoft.Practices.EnterpriseLibrary.Logging library for logging in our web application and the problem i开发者_运维技巧s that it writes the log with 1 hour difference from the current system time.

Our logger is based on this article and the time in a log entry is never set in code by us. Every log entry has a title which looks like this:

MainLogSource Information: 0 : Timestamp: 11/04/2011 10:15:32 so this timestamp always 1 hour earlier than system time (e.g. this entry appeared at 11:15).

Where can be the problem? Thanks

---

By default Enterprise Library logs using UTC timestamp, so these are unaffected by daylight savings time.

You can change the formatter in the .config file to use local time (see attached question), but be aware that this will result in duplicate entries when daylight savings time changes occur.

Enterprise Library 5.0 - Application Logging - Incorrect DateTime

---

Cultural ignorance of one side of the comparison?

As in: the logger writes out the time in UTC and you compare it to the local system time and just happen to have it set to a one hour difference? Central Europe, for example, is 1 hour ahead of UTC time (half of the year).

What are your locale settings? This is a quite common phenomenon. Basically to be comparable loggers etc. LOVE setting things in UTC, and you should do so, too. I know companies running the servers in UTC time locale wise so it is easier to compare logs to the system clock (at the price to the system clock always being off).

---

This is probably because EntLib by default logs timestamps in UTC. You can override this see here

---

Set the TimeStamp property of LogEntry class in your code. You can set it to your local time. This will reflect at both places : TimeStamp and ExtendedProperties. Like Below:

    var newLog = new LogEntry(objException.Message, "General", 1, 1, TraceEventType.Error, "YourApp", null);
    newLog.TimeStamp = DateTime.Now;

---

There are a couple of possibilities that spring to mind:

• The clock on which ever machine is running the the application hasn't been adjusted for daylight saving time.

• When getting the time you are requesting it as UTC rather than the current locale's time zone.