I looked into the plugin yesterday, and the method being used to convert '05/10/2010' or whatever into a date object is dateWithNaturalLanguageString:
see - http://developer.apple.com/mac/library/documentation/Cocoa/Reference/Foundation/Classes/NSDate_Class/Reference/Reference.html#//apple_ref/occ/clm/NSDate/dateWithNaturalLanguageString : I tried changing it to dateWithNaturalLanguageString:locale: thinking that would work, but unfortunately not. It should have done, which is strange. Unless this is broken in SL - apparently it was broken in 10.5 up until 10.5.2 I'm pretty sure this isn't a problem with QS itself, so I don't know :( 2010/1/21 Jon Stovell (a.k.a. Sesquipedalian) <[email protected]> > This might be caused by an incomplete implementation at the operating > system level of your localized date format. > > For example, Canadian date formats were only fully implemented in 10.6 > (or maybe 10.5) which meant that in earlier versions of Mac OS X, date > related functions could sometimes break. So if I had some AppleScript > code, for example, that took some text (e.g. "1/2/2010") and converted > it to a date (e.g. in order to create an iCal event at a certain > date), the conversion might not go correctly if I had a Canadian > localization in effect in System Preferences. Because the Canadian > localization was not fully implemented, AppleScript would fall back to > whatever localization I had previously selected in System Preferences > that was fully implemented. So if sometime in the past I had switched > my localization region from United States to Canada, AppleScript would > interpret "1/2/2010" as January 2, 2010 instead of February 1, 2010 > (which is what I meant). However, if I went into System Preferences > and changed my region to the United Kingdom and then back to Canada, > then the next time AppleScript ran the code, it would correctly > interpret "1/2/2010" as February 1, 2010, because the UK uses the same > order that Canada does. In 10.6 this is no longer a problem for > Canadian formats, because they are fully supported. > > It was easy to tell if a particular localization was fully implemented > and supported, because System Preferences would show a warning icon > and some explanatory text whenever I selected one. > > Of course, it might not be this at all, and perhaps the plugin itself > is improperly coded. > > On Jan 19, 5:01 am, jsilence <[email protected]> wrote: > > On 7 Jan., 20:41, Patrick Robertson <[email protected]> > > wrote: > > > > > If you're having problems with choosing a calendar, and you're on > Leopard or > > > Snow Leopard, it's most probably because of a change in iCal in these > > > versions. > > > > > I'd suggest looking at: > > > github.com/tiennou/blacktree-elements/downloads > > > > > for an updated iCal plugin and seeing if that works :) > > > > With Version 1.0.2 my calendars show up in the list. Thanks! > > Unfortunately only the local calendars and not my CalDAV calendars. > > > > Thgere seems to be a minor Bug with the european date entry parsing. > > If I enter 21.01.2010, then the entry is made on the 19th. Apart from > > that the usage of the european format ist inconsistent: > > > > 15.2.07 -- feb 15th 2007, cause 15 can't be a month > > 3.2.07 -- march 2nd 2007!! > > > > (fromhttp://docs.blacktree.com/quicksilver/plug-ins/ical) > > > > This can be very confusing and is error prone for the users, because > > now they have to ask themselves: "Can the first number be interpreted > > as a month? If so, swap the numbers." > > > > It would be great if that would be fixed into a consistent european > > format which is always dd.mm.yyyy. > > > > Best regards, > > > > -jsl >
