Hi,
Here is a patch which reverts a patch for NSCalendarDate I once send. Things
have changed since then, and now the old code seems much better again.
The major abbreviations like CET have a time zone file associated. So it is
perfect for most cases to load this file directly as name (as it was once
before). In case this fails, the zone is tried to be loaded by it's mapped
abbreviation.
This approach now works, because an exception has been removed from the code.
My problem with the current code:
With the current code a wrong time zone is loaded for a given abbreviation,
because [NSTimeZone timeZoneWithAbbreviation:] is based upon the abbreviation
list. If I want CET, I get Africa/Cassablanca, which would turn back into
WET...
Another approach to fix this would be to fix [NSTimeZone
timeZoneWithAbbreviation:] to return the zone file with the name of the
abbreviation, if available. Fixing this would be correct anyway.
Probably both should be done.
Georg
2004-10-05 Georg Fleischmann
* base/Source/NSCalendarDate.m [-initWithString:]
return to previous code, and
try to load time zone abbreviation from name, first.
*** base/Source/NSCalendarDate.m.old 2004-06-23 21:13:50.000000000 +0200
--- base/Source/NSCalendarDate.m 2004-09-29 04:36:23.000000000 +0200
***************
*** 1132,1145 ****
{
NSString *z = [NSString stringWithCString: tmpStr];
! if ([[NSTimeZone abbreviationDictionary] objectForKey: z])
{
tz = [NSTimeZone timeZoneWithAbbreviation: z];
}
- else
- {
- tz = [NSTimeZone timeZoneWithName: z];
- }
}
break;
--- 1132,1142 ----
{
NSString *z = [NSString stringWithCString: tmpStr];
! tz = [NSTimeZone timeZoneWithName: z];
! if (tz == nil)
{
tz = [NSTimeZone timeZoneWithAbbreviation: z];
}
}
break;
_______________________________________________
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
