publicdomain Work Item Rss Feed

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

schizoidboy — Thu, 16 May 2013 06:58:35 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));
...
}

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

MARIOIGREC — Thu, 16 May 2013 06:58:34 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.

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

schizoidboy — Thu, 16 May 2013 06:58:34 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

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

schizoidboy — Thu, 16 May 2013 06:58:34 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.

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.

Created Issue: Recent Olson Data Changes Crash Public Domain

mlmanfredi — Mon, 08 Jun 2009 15:37:58 GMT

Created Issue: Code\CodeUtilities.cs: VisualBasic ReferencedAssemblies, fixed paths issue

CoolSpin — Fri, 01 May 2009 15:54:08 GMT

Hi.

http://publicdomain.codeplex.com/SourceControl/changeset/view/41779#308775
File: Code\CodeUtilities.cs:172-173

Problem:
compilerParameters.ReferencedAssemblies.Add(@"c:\windows\Microsoft.NET\Framework\v2.0.50727\System.dll");
compilerParameters.ReferencedAssemblies.Add(@"c:\windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll");

Paths are static, its not given that the Windows directory will always be C:\WINDOWS.

Possible solutions:

http://msdn.microsoft.com/en-us/library/system.environment.specialfolder(VS.71).aspx
with
http://msdn.microsoft.com/en-us/library/system.environment.getfolderpath(VS.71).aspx

string systemdir = Environment.GetFolderPath(Environment.SpecialFolder.System)

This will result in $windowsdir\System32. You can then check for the existense of the special files File.Exists() or check the parent directory:

systemdir += ".." + Path.DirectorySeparatorChar + "Microsoft.Net.....";
File.Exists(systemdir)

Or you can read the following registry key:
HKLM\SOFTWARE\Microsoft\.NETFramework\[REG_SZ:InstallRoot]
Which should return: C:\WINDOWS\Microsoft.NET\Framework\

Very practical library, if not directly used, then as reference.

Commented Issue: Southern hemisphere: GetDaylightChanges.Start and .End are reversed

AlanBirenbaum — Wed, 14 Jan 2009 23:34:58 GMT

In PublicDomain.TzTimeZone, GetDaylightChanges(iDSTYear).Start and GetDaylightChanges(iDSTYear).End return reverse values (.Start returns a DST off value and .End the DST on value) for time zone locales in the southern hemisphere.

Examples are 'Pacific/Auckland', all Australian TZs with DST offset such as 'Australia/Adelaide', 'America/Sao_Paulo', etc.
Comments: ** Comment from web user: AlanBirenbaum **

Seems that you also need to modify the else if in the TzTimeZone PrepOffset routine as follows:

private void PrepOffset(ref DateTime time, ref TimeSpan result, PublicDomain.TzDatabase.TzZone zone)
{
// First, figure out which zone we're in
DateTime point = new DateTime(time.Year, 1, 1);

PublicDomain.TzDatabase.TzRule one;
PublicDomain.TzDatabase.TzRule two;
DaylightTime daylightTime;

GetDaylightChangeRules(ref point, zone, DateTimeKind.Local, out one, out two, out daylightTime);

if (daylightTime != null && daylightTime.Start < daylightTime.End && time >= daylightTime.Start && time < daylightTime.End)
{
result += one.SaveTime;
}
//**orig** else if (daylightTime != null && daylightTime.Start > daylightTime.End && (time <= daylightTime.Start || time > daylightTime.End))
// ! check that it's NOT standart time
else if (daylightTime != null && daylightTime.Start > daylightTime.End && !(time >= daylightTime.End && time < daylightTime.Start))
{
result += one.SaveTime;
}
}

Commented Issue: GetHashCode() seems to return different numbers in x86 and x64

CHolt — Wed, 10 Dec 2008 19:09:11 GMT

Therefore, when recompile the code in x64, the function GetTimeZone returns null, because the hash doesn't match the hard coded ones.
How can I solve this?
Thanks,
Nestor
Comments: ** Comment from web user: CHolt **

This seems like it might be fixed in the latest version. I just downloaded the source to make the changes necessary to get around it and it looks like the switch statement has been changed to switch off of strings.

Commented Issue: GetHashCode() seems to return different numbers in x86 and x64

CHolt — Wed, 10 Dec 2008 18:38:54 GMT

I am having the same problem. I think this is a bit more serious than a low impact.

Created Issue: GetHashCode() seems to return different numbers in x86 and x64

nsulikow — Wed, 16 Jul 2008 06:20:44 GMT

Therefore, when recompile the code in x64, the function GetTimeZone returns null, because the hash doesn't match the hard coded ones.
How can I solve this?
Thanks,
Nestor

Commented Issue: TzTimeZone.CurrentTimeZone returns GMT and not BST for UK windows DST settings

MathiasHolmgren — Tue, 24 Jun 2008 12:09:59 GMT

During the summer the UK uses BST, not strict GMT, see http://wwp.greenwichmeantime.com/time-zone/europe/uk/.
Comments: ** Comment from web user: MathiasHolmgren **

To reproduce, change windows time zone to the GMT time zone (London) AND check the "automatically adjust clock for daylight saving changes".

The TzTimeZone.CurrentTimeZone will incorrectly return a UTC time zone object which returns null for this method call (when 'today' is i.e. june 24 2008):
TzTimeZone.CurrentTimeZone.GetDaylightChanges(2008)

It should return a western european summer time zone (preferably), OR a BST time zone OR an UTC time zone WITH daylight changes dates set.

It would be awesome if PublicDomain would have full support for Western European Time and not just strict UTC, which seems to have no or incomplete DST support. This is an important feature for any application performing european time zone conversion

Hint: The world's #1 financial center is London :)

Created Issue: TzTimeZone.CurrentTimeZone returns GMT and not BST for UK windows DST settings

MathiasHolmgren — Tue, 24 Jun 2008 11:58:23 GMT

During the summer the UK uses BST, not strict GMT, see http://wwp.greenwichmeantime.com/time-zone/europe/uk/.

Commented Issue: Windows Brazil -3 GMT Tz becomes TimezoneAmericaNoronha CurrentTimeZone

MathiasHolmgren — Mon, 23 Jun 2008 09:05:22 GMT

To reproduce:
Comments: ** Comment from web user: MathiasHolmgren **

Also, the UtcOffset for the TimezoneAmericaArgentinaBuenosAires timezone for todays date (june 23 2008 09:00 GMT) is -2, not -3 as I would expect. "Now" is therefore 07:00 in brazil time zone when I would expect it to be 06:00, which is also what windows shows when switching to the brazil time zone.

Who is correct, Windows or PublicDomain?

Commented Issue: Windows Brazil -3 GMT Tz becomes TimezoneAmericaNoronha CurrentTimeZone

MathiasHolmgren — Mon, 23 Jun 2008 08:57:08 GMT

To reproduce:
Comments: ** Comment from web user: MathiasHolmgren **

Set the time zone in windows to -3 GMT Brazil.

The TzTimeZone.CurrentTimeZone property will return the America/Noronha -2 GMT timezone. This can't be right.

Created Issue: Windows Brazil -3 GMT Tz becomes TimezoneAmericaNoronha CurrentTimeZone

MathiasHolmgren — Mon, 23 Jun 2008 08:53:01 GMT

To reproduce:

CREATED ISSUE: GetAbbreviation is still a problem

mlmanfredi — Tue, 05 Feb 2008 16:59:24 GMT

The fix for work item #12541 has a problem. If you swap rules in the GetAbbreviation function, the companion rule’s modifier will never be used. See the fixed code below. Also, does this need the same “IsLatitudeNorth” fix that was put into the GetDaylightChangeRules function?

Thanks,
Mike

Fixed code:
public virtual string GetAbbreviation(DateTime time)
{
PublicDomain.TzDatabase.TzZone zone = FindZone(time);
int rule1Index = FindRuleIndex(zone, time);
PublicDomain.TzDatabase.TzRule rule1 = (rule1Index == -1 ? null : m_info.Rules[rule1Index]);
if (rule1 != null)
{
PublicDomain.TzDatabase.TzRule modrule = rule1;
PublicDomain.TzDatabase.TzRule rule2 = GetCompanionRule(zone, rule1, rule1Index, time);
if (rule2 != null)
{
DateTime x = rule1.GetDateTime(time.Year, zone.UtcOffset);
DateTime y = rule2.GetDateTime(time.Year, zone.UtcOffset);

if (x > y)
{
DateTime swap = y;
y = x;
x = swap;

PublicDomain.TzDatabase.TzRule swapRule = rule1;
rule1 = rule2;
rule2 = swapRule;
}

if (time < x)
{
modrule = rule2;
}
else if (time >= x && time < y)
{
modrule = rule1; // Adding this line fixes the problem
}
else
{
modrule = rule2;
}
}

return zone.FormatModifier(modrule);
}
else if (zone != null && !string.IsNullOrEmpty(zone.Format) && zone.Format != TzDatabase.NotApplicableValue)
{
return zone.Format;
}
return StandardName;
}

COMMENTED ISSUE: GetDaylightChanges returns rules for zones which no longer operate daylight savings

AlanBirenbaum — Tue, 22 Jan 2008 14:57:42 GMT

For example, according to the Olson database, America/Barbados last operated daylight savings in 1980, but GetDaylightChanges indicates that Daylight savings time exists, and indicates that the start time and the end time are equal. So, for America/Barbados 2008: DST starts 25.09 at 2:00...
DST ends 25.09 at 2:00.

It appears that if FindRuleIndex cannot find a rule to cover the given year, it returns the last rule in the set. Excerpt from FindRuleIndex, with my comments below:

for (int j = 0; j < rulesLength; j++)
{
PublicDomain.TzDatabase.TzRule r = m_info.Rules[j];
if (r.RuleName == ruleName)
{
curRuleIndex = j; // curRuleIndex is set when a matching rule name is found, but before the check to see if it applies to the given year
if ((exactComparison && point >= r.GetFromDateTime(zone.UtcOffset) && point < r.GetToDateTime(zone.UtcOffset)) ||
(!exactComparison && point.Year >= r.FromYear && point.Year <= r.ToYear))
{
if (avoidModifier == null || avoidModifier != r.Modifier)
{
break;
}
}
// I suspect that something similar to the following should be added
else
{
curRuleIndex = -1;
}
// end of code addition
}
}

if (curRuleIndex == -1)
{
throw new Exception("Could not find rule"); // in the original code, this will never happen if any rules match the ruleName
}
}
return curRuleIndex;

Of course, some exception handling would need to be added in the higher-level functions.

For reference, the rules for Barbados are below:
# Barbados
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
Rule Barb 1977 only - Jun 12 2:00 1:00 D
Rule Barb 1977 1978 - Oct Sun>=1 2:00 0 S
Rule Barb 1978 1980 - Apr Sun>=15 2:00 1:00 D
Rule Barb 1979 only - Sep 30 2:00 0 S
Rule Barb 1980 only - Sep 25 2:00 0 S
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone America/Barbados -3:58:28 - LMT 1924 # Bridgetown
-3:58:28 - BMT 1932 # Bridgetown Mean Time
-4:00 Barb A%sT
Comments: ** Comment from web user: AlanBirenbaum **

It seems that this issue was delt with / fixed in version 0.2.39.0. Correct?

COMMENTED ISSUE: GetDaylightChanges returns rules for zones which no longer operate daylight savings

stephenbt — Thu, 10 Jan 2008 21:27:53 GMT

See patch 673 for a proposed solution.