PublicDomain

Reopened Issue: Wrong calculation of number in FileSizeRollOverStrategy.GetFileName() [12363]

schizoidboy — Fri, 14 Jun 2013 06:47:08 GMT

The maximum integer number is not correctly calculated if the path to the logfile directory contains digit(s). The code GetFileName() should be changed to:

public string GetFileName(string fileName, LoggerSeverity severity, DateTime timestamp, object entry, object[] formatParameters, string logLine)
{
...
int foundNumber = StringUtilities.ExtractFirstNumber(Path.GetFileName(foundFile));
...
}

Reopened Issue: Time zone remaining ToUniversalTime and ToLocalTime issues [12480]

MARIOIGREC — Fri, 14 Jun 2013 06:47:08 GMT

Sorry about the delay in my response. I tested your last round of fixes and we are now much closer to having it working right.

Thanks for letting me know about DateTimeKind.Utc. I made DateTimeKind explicit in all my tests, for example:

zone.ToUniversalTime(New DateTime(DateTime.Parse("2008-03-30 00:00").Ticks, DateTimeKind.Local))

You said "Also, I don't think the ToLocalTime tests are really valid on the boundary cases." I know, you should never have a case of '2006-04-02 02:30' in America/Chicago time zone since 2 am becomes 3 am, creating an hour 'hole'. I think you are doing the right thing in this case by applying the DST rule and not worrying about this "invalid" hour:

zone.ToUniversalTime('2006-04-02 01:00'): '4/2/2006 7:00:00 AM'
zone.ToUniversalTime('2006-04-02 01:30'): '4/2/2006 7:30:00 AM'
zone.ToUniversalTime('2006-04-02 02:00'): '4/2/2006 7:00:00 AM'
zone.ToUniversalTime('2006-04-02 02:30'): '4/2/2006 7:30:00 AM'

The same (repeated hour) issue affects .ToLocalTime when DST goes off. Again, you are doing the right thing IMO.

The remaining issues revolve around the interpretation of the DST switchover time rule. The Olsen database uses several letters to indicate how the DST switch time should be interpreted. Here are a few examples:

---------------------------------------------------
DST rule name Valid on/off Date Time Offset
---------------------------------------------------
No letter:
US >= 2007 on Mar Sun>=8 2:00 1:00
'u':
EU on Mar lastSun 1:00u 1:00
's':
Russia on Mar lastSun 2:00s 1:00

The key to interpreting the letter is (see http://home.tiscali.nl/~t876506/TZworld.html):

no letter or w: wall clock time, actual local time.
s: local standard time (winter time)
u or g or z: UTC time.
So, if a 'DST on' time is given as '2:00s', this means a switch on 2:00 local time. If a 'DST off' time is given as '2:00s', this means a switch on 3:00 local time (assuming a DST offset of 1 hour).

In zone.ToUniversalTime and zone.ToLocalTime, the switchover time is not always interpreted correctly. Here are the use cases. Please see a complete listing of use case results and the source code in the attached file 'UTC Testing.rtf' to see the results for dates in different years.

1. America/Chicago (rule for 2006: Apr Sun>=1 2:00 [local time]): ToUniversalTime switchover time is correct:

zone.ToUniversalTime('2006-04-02 01:00'): '4/2/2006 7:00:00 AM'
zone.ToUniversalTime('2006-04-02 01:30'): '4/2/2006 7:30:00 AM'
zone.ToUniversalTime('2006-04-02 02:00'): '4/2/2006 7:00:00 AM' <- switchover is correct
zone.ToUniversalTime('2006-04-02 02:30'): '4/2/2006 7:30:00 AM'

2. America/Chicago (rule for 2006: Apr Sun>=1 2:00 [local time]): ToLocalTime interprets the switchover time as UTC (u) instead of local. The switch occurs at 2am UTC time (9 pm on the preceding day local time) instead of 8 am UTC time (2 am local):

zone.ToLocalTime('2006-04-02 01:30'): '4/1/2006 7:30:00 PM'
zone.ToLocalTime('2006-04-02 02:00'): '4/1/2006 9:00:00 PM' <- switchover occurs here (2:00 UTC)
zone.ToLocalTime('2006-04-02 02:30'): '4/1/2006 9:30:00 PM'
zone.ToLocalTime('2006-04-02 03:00'): '4/1/2006 10:00:00 PM'
zone.ToLocalTime('2006-04-02 07:00'): '4/2/2006 2:00:00 AM' <- instead of here (2:00 local actual time)
zone.ToLocalTime('2006-04-02 07:30'): '4/2/2006 2:30:00 AM'

3. Europe/Paris (Mar lastSun 1:00u - 'u' means 'UTC'): ToUniversalTime acts as if the switchover time is expressed in local time:

zone.ToUniversalTime('2007-03-25 00:00'): '3/24/2007 11:00:00 PM'
zone.ToUniversalTime('2007-03-25 00:30'): '3/24/2007 11:30:00 PM'
zone.ToUniversalTime('2007-03-25 01:00'): '3/24/2007 11:00:00 PM' <- switchover occurs here (1:00 local time)
zone.ToUniversalTime('2007-03-25 01:30'): '3/24/2007 11:30:00 PM'
zone.ToUniversalTime('2007-03-25 02:00'): '3/25/2007' <- and should occur of here (1:00 UTC)

4. Europ/Paris (Mar lastSun 1:00u - 'u' means 'UTC'): ToLocalTime switchover time is correct:

zone.ToLocalTime('2007-03-25 00:00'): '3/25/2007 1:00:00 AM'
zone.ToLocalTime('2007-03-25 00:30'): '3/25/2007 1:30:00 AM'
zone.ToLocalTime('2007-03-25 01:00'): '3/25/2007 3:00:00 AM' <- switchover is correct
zone.ToLocalTime('2007-03-25 01:30'): '3/25/2007 3:30:00 AM'

5. Europe/Moscow (Mar lastSun 2:00s = 's' means 'local standard time'): when standard time is switching to DST, .ToUniversalTime acts correctly. This is probably because at this point local actual time and local standard time are the same:

zone.ToUniversalTime('2007-03-25 01:00'): '3/24/2007 10:00:00 PM'
zone.ToUniversalTime('2007-03-25 01:30'): '3/24/2007 10:30:00 PM'
zone.ToUniversalTime('2007-03-25 02:00'): '3/24/2007 10:00:00 PM' <- switchover is correct
zone.ToUniversalTime('2007-03-25 02:30'): '3/24/2007 10:30:00 PM'

6. Europe/Moscow (Mar lastSun 2:00s = 's' means 'local standard time'): when DST is switching to standard time, .ToUniversalTime acts as if the switchover time rule is expressed in local time and not in local standard time:

zone.ToUniversalTime('2007-10-28 01:00'): '10/27/2007 9:00:00 PM'
zone.ToUniversalTime('2007-10-28 01:30'): '10/27/2007 9:30:00 PM'
zone.ToUniversalTime('2007-10-28 02:00'): '10/27/2007 11:00:00 PM' <- switchover occurs here (01:00 'standard time')
zone.ToUniversalTime('2007-10-28 02:30'): '10/27/2007 11:30:00 PM'
zone.ToUniversalTime('2007-10-28 03:00'): '10/28/2007' <- and should occur here (02:00 'standard time')
zone.ToUniversalTime('2007-10-28 03:30'): '10/28/2007 12:30:00 AM'

7. Europe/Moscow (Mar lastSun 2:00s = 's' means 'local standard time'): ToLocalTime acts as if the switchover time is expressed in UTC and not local standard time:

zone.ToLocalTime('2007-03-24 23:00'): '3/25/2007 2:00:00 AM' <- switchover should occur here (2:00 'standard time')
zone.ToLocalTime('2007-03-25 01:00'): '3/25/2007 4:00:00 AM'
zone.ToLocalTime('2007-03-25 01:30'): '3/25/2007 4:30:00 AM'
zone.ToLocalTime('2007-03-25 02:00'): '3/25/2007 6:00:00 AM' <- instead of here (2:00 UTC)
zone.ToLocalTime('2007-03-25 02:30'): '3/25/2007 6:30:00 AM'

Example 2:

zone.ToLocalTime('2007-10-27 23:00'): '10/28/2007 3:00:00 AM' <- switchover should occur here (2:00 'standard time' or 3:00 local actual time)
zone.ToLocalTime('2007-10-28 01:00'): '10/28/2007 5:00:00 AM'
zone.ToLocalTime('2007-10-28 01:30'): '10/28/2007 5:30:00 AM'
zone.ToLocalTime('2007-10-28 02:00'): '10/28/2007 5:00:00 AM' <- instead of here (2:00 UTC)
zone.ToLocalTime('2007-10-28 02:30'): '10/28/2007 5:30:00 AM'

8. Related issue: zone.GetDaylightChanges doesn't appear to indicate whether the switchover datetime is UTC, local current time, or local standard time. It might be useful to accept a parameter in this method that specifies which of the 3 times one wants returned. Or, constrain it to UTC? Personally, I don't need this, but it will probably come up as an issue for someone:

zone.GetDaylightChanges(2007).Start: '3/11/2007 2:00:00 AM'

Thanks in advance.

Reopened Issue: Problems getting correct time zone abbreviation [12541]

schizoidboy — Fri, 14 Jun 2013 06:47:08 GMT

I am writing code in VB.NET and I am having problems getting the correct time zone abbreviation for dates that are not during daylight savings time. For instance I run the following code:

Dim startDate As Date = "1/1/2008 12:00:00"
Dim abbrev As String
abbrev = PublicDomain.TzTimeZone.GetTimeZone("America/Denver").GetAbbreviation(startDate)

This code should set the abbrev variable to MST because 1/1/2008 is not during daylight saving time. However a value of MDT is returned. I would appreciate any assistance in getting this issue resolved. Thanks

Reopened Issue: ObjectUtilities.SerializeObjectToBinary(object o) is returning wrong buffer. [12958]

schizoidboy — Fri, 14 Jun 2013 06:47:08 GMT

The ObjectUtilities.SerializeObjectToBinary(object o) function is returning the buffer obtained via MemoryStream.GetBuffer() which is an internal buffer maintained by MemoryStream and is not supported to hold the exact serialized bytes (will contain extra bytes at the end). The fix would be to use MemoryStream.ToArray() function.

The issue can be confirmed by comparing the return byte[] of GetBuffer() and ToArray() functions. The former would be bigger than the latter as it would contain unused space at the end.

The current implementation might still work in most of the cases, but it is not the right thing by principle.

Closed Issue: Wrong calculation of number in FileSizeRollOverStrategy.GetFileName() [12363]

schizoidboy — Thu, 16 May 2013 06:58:35 GMT

Closed Issue: Time zone remaining ToUniversalTime and ToLocalTime issues [12480]

MARIOIGREC — Thu, 16 May 2013 06:58:34 GMT

Closed Issue: Problems getting correct time zone abbreviation [12541]

schizoidboy — Thu, 16 May 2013 06:58:34 GMT

Closed Issue: ObjectUtilities.SerializeObjectToBinary(object o) is returning wrong buffer. [12958]

schizoidboy — Thu, 16 May 2013 06:58:34 GMT

Source code checked in, #99885

Project Collection Service Accounts — Mon, 01 Oct 2012 21:24:31 GMT

Upgrade: New Version of LabDefaultTemplate.xaml. To upgrade your build definitions, please visit the following link: http://go.microsoft.com/fwlink/?LinkId=254563

Source code checked in, #99884

Project Collection Service Accounts — Mon, 01 Oct 2012 21:16:08 GMT

Checked in by server upgrade

Commented Issue: Recent Olson Data Changes Crash Public Domain [22980]

mlmanfredi — Wed, 23 Mar 2011 15:24:25 GMT

The 2009h update has the following change...
OLD: Rule\tJordan\t2002\tmax\t-\tMar\tlastFri\t0:00s\t1:00\tS
NEW: Rule\tJordan\t2002\tmax\t-\tMar\tlastThu\t24:00\t1:00\tS

The ParseTimeSpan function in DateTimeUtilities.cs chokes on this because TimeSpan.Parse can't handle "24:00".
Comments: ** Comment from web user: mlmanfredi **

Thanks for the suggestion. My current workaround for the problem is to alter the original value from 24:00 to 23:59:59. I don't think the one second is going to make any difference for me.

Commented Issue: Recent Olson Data Changes Crash Public Domain [22980]

bbell2000 — Sat, 19 Mar 2011 15:12:58 GMT

There are two ways to get around this issue. The first way is to edit tzdata\asia to apply year-specific rules for the years in which Apr 1 occurs on a Friday. This is the same approach used in tzdata\northamerica to get around the same issue in the Mont rules for 1927-1937.

# The 2006-to-max rules can be expressed more simply as
# Rule Jordan 2002 max - Mar lastThu 24:00 1:00 S
# The rules below avoid use of 24:00 through 2051
# (which TimeZone.Parse cant handle).
Rule Jordan 2002 2004 - Mar lastFri 0:00 1:00 S
Rule Jordan 2003 only - Oct 24 0:00s 0 -
Rule Jordan 2004 only - Oct 15 0:00s 0 -
Rule Jordan 2005 only - Apr 1 0:00 1:00 S
Rule Jordan 2005 only - Sep lastFri 0:00s 0 -
Rule Jordan 2006 2010 - Mar lastFri 0:00 1:00 S
Rule Jordan 2006 max - Oct lastFri 0:00s 0 -
Rule Jordan 2011 only - Apr 1 0:00 1:00 S
Rule Jordan 2012 2015 - Mar lastFri 0:00 1:00 S
Rule Jordan 2016 only - Apr 1 0:00 1:00 S
Rule Jordan 2017 2021 - Mar lastFri 0:00 1:00 S
Rule Jordan 2022 only - Apr 1 0:00 1:00 S
Rule Jordan 2023 2032 - Mar lastFri 0:00 1:00 S
Rule Jordan 2033 only - Apr 1 0:00 1:00 S
Rule Jordan 2034 2038 - Mar lastFri 0:00 1:00 S
Rule Jordan 2039 only - Apr 1 0:00 1:00 S
Rule Jordan 2040 2043 - Mar lastFri 0:00 1:00 S
Rule Jordan 2044 only - Apr 1 0:00 1:00 S
Rule Jordan 2045 2049 - Mar lastFri 0:00 1:00 S
Rule Jordan 2050 only - Apr 1 0:00 1:00 S
Rule Jordan 2051 max - Mar lastFri 0:00 1:00 S

The second way is to change DateTimeUtilities.cs:

public static bool TryParseTimeSpan(string timeSpan, TimeSpanAssumption noColonAssumption, out TimeSpan result)
{
if (timeSpan != null && timeSpan[0] == '+')
{
timeSpan = timeSpan.Substring(1);
}

timeSpan = ParseTimeSpanAssumptions(timeSpan, noColonAssumption);

if (!TimeSpan.TryParse(timeSpan, out result))
{
timeSpan = timeSpan.Replace("24:00", "1.00:00");
return TimeSpan.TryParse(timeSpan, out result);
}

return true;
}

public static TimeSpan ParseTimeSpan(string timeSpan, TimeSpanAssumption noColonAssumption)
{
if (timeSpan != null && timeSpan[0] == '+')
{
timeSpan = timeSpan.Substring(1);
}

timeSpan = ParseTimeSpanAssumptions(timeSpan, noColonAssumption);

TimeSpan result;
if (!TimeSpan.TryParse(timeSpan, out result))
{
timeSpan = timeSpan.Replace("24:00", "1.00:00");
result = TimeSpan.Parse(timeSpan);
}

return result;
}

Either way, it's a hack. YMMV.

New Post: warning CS1734: XML comment

orellabac — Sat, 18 Dec 2010 21:45:01 GMT

There just some methods that have xml comment errors. How can I modify the online code to fix those errors?

New Post: warning CS1734: XML comment

orellabac — Sat, 18 Dec 2010 21:45:01 GMT

There just some methods that have xml comment errors. How can I modify the online code to fix those errors?

Source code checked in, #74794

_TFSSERVICE — Tue, 03 Aug 2010 19:44:57 GMT

Checked in by server upgrade

New Post: Changed location for external link

BruceClement — Tue, 15 Jun 2010 01:26:19 GMT

The referenced codeproject article "How to Use the Olson Time Zone Database in .NET" is now at http://www.codeproject.com/KB/dotnet/Using_time_zones_in_NET.aspx

It looks like they've restructured their site.

New Post: Changed location for external link

BruceClement — Tue, 15 Jun 2010 01:26:19 GMT

The referenced codeproject article "How to Use the Olson Time Zone Database in .NET" is now at http://www.codeproject.com/KB/dotnet/Using_time_zones_in_NET.aspx

It looks like they've restructured their site.

New Post: Changed location for external link

BruceClement — Tue, 15 Jun 2010 01:26:19 GMT

The referenced codeproject article "How to Use the Olson Time Zone Database in .NET" is now at http://www.codeproject.com/KB/dotnet/Using_time_zones_in_NET.aspx

It looks like they've restructured their site.

New Post: DST offset wrong for southern hemisphere

MARIOIGREC — Thu, 10 Sep 2009 15:23:01 GMT

A while back I reported an issue with DST for southern hemisphere locations. Originally, in version 0.2.30.0, DST start and end dates were reversed. For example, today on Sep 10, 2009, Canberra, Melbourne, Sydney location, which normally has GTM +10:00 would return:

- DST: On (incorrect)
- DST Offset: +01:00 (incorrect)
- DST Starts: 2009-04-05 03:00 (incorrect)
- DST Ends: 2009-10-04 02:00 (incorrect)
- Time Zone Offset from GMT: +10:00 (correct)

The fix, which is the most recent version (0.2.47.0), looks like this:

- DST: Off (correct)
- DST Offset: 00:00 (correct)
- DST Starts: 2009-10-04 02:00 (correct)
- DST Ends: 2009-04-05 03:00 (correct)
- Time Zone Offset from GMT: +11:00 hours (incorrect)

From what I see, this affects all southern hemisphere time zones with DST (fortunately there aren't that many). You may want to be aware of this and correct the wrong values in your code.

Here are PublicDomain.TzTimeZone methods that demonstrate how I get each of the above values. I took these out of my Time Zone test page where I have a lot of additional code, so I haven't tested these raw calls. You may have to replace now with a datetime variable which you explicitly set to local or UTC with DateTime.SpecifyKind(dtVariable, DateTimeKind.Local).

Dim zone As PublicDomain.TzTimeZone
Dim sZone as string
sZone = "Australia/Melbourne"
'sZone = "America/Sao_Paulo"
zone = PublicDomain.TzTimeZone.GetTimeZone(sZone)
'Time Zone Offset from GMT: zone.GetUtcOffset(now)
'DST: zone.IsDaylightSavingTime(now)
'DST Offset: zone.GetDaylightChanges(now.year).Delta.Hours.ToString & ":" & zone.GetDaylightChanges(2009).Delta.Minutes.ToString
'DST Starts: zone.GetDaylightChanges(now.year).Start
'DST Ends: zone.GetDaylightChanges(now.year).End

New Post: DST offset wrong for southern hemisphere

MARIOIGREC — Thu, 10 Sep 2009 15:23:01 GMT

- DST: On (incorrect)
- DST Offset: +01:00 (incorrect)
- DST Starts: 2009-04-05 03:00 (incorrect)
- DST Ends: 2009-10-04 02:00 (incorrect)
- Time Zone Offset from GMT: +10:00 (correct)

The fix, which is the most recent version (0.2.47.0), looks like this:

- DST: Off (correct)
- DST Offset: 00:00 (correct)
- DST Starts: 2009-10-04 02:00 (correct)
- DST Ends: 2009-04-05 03:00 (correct)
- Time Zone Offset from GMT: +11:00 hours (incorrect)

From what I see, this affects all southern hemisphere time zones with DST (fortunately there aren't that many). You may want to be aware of this and correct the wrong values in your code.