In general dealing with time zones is a bit of a nightmare (just like text encodings). Another problem is that governments can change when and how their time zones work and if they use daylight savings times or not.
So what is the current time zone offset for NewYork? Or the EastCoast? I don't think it is that easy to work out if a place has Daylight Savings Time at the moment. The TimeZone class would have the information but as far as I can see you can only get the TimeZone information for the current computer. We would need some way to get accurate time zone information for the whole world otherwise it isn't really a viable solution. Ideally we would say that you should always store UTC dates in your log files and that the viewer app is responsible for displaying the date in local time, however when the viewer is notepad it can get quite annoying to remember the offsets. Nicko > -----Original Message----- > From: Ron Grabowski [mailto:[EMAIL PROTECTED] > Sent: 07 October 2005 19:27 > To: Log4NET Dev > Subject: RE: %date pattern and timezones > > --- Nicko Cadell <[EMAIL PROTECTED]> wrote: > > > %date{format='''DATE: ''yyyy-MM-dd ''TIME: ''hh:mm:ss > > tt',hourOffset=-4} > > That's ugly! This isn't much better...it gets rid of the quotes: > > DATE: %d{format=yyyy-MM-dd,hourOffset=-4} TIME: %d{t,hourOffset=-4} > > > My only problem with the code is that some places use half hour > > increments in the timezone offset so the hourOffset must be > a float or > > something like that so that Australian Central Daylight > Time can have > > hourOffset=10.5 > > Someone contacted me off list suggesting we could use well > known city name constants like New_York so we would wouldn't > have to handle changing between Daylight Time and Normal > Time. He also pointed out that if someone doesn't change the > -4 to a -5 when Normal Time starts there will be log files > with incorrect dates in them. Another good idea would be to > recommend that people continue to store UTC time in their log > files and use this new notation only as a quick method for > converting to local time. If the date appeared in UTC then it > wouldn't matter if the hourOffset didn't get changed at the > exact time that Daylight Time began/ended. > >
