[Pythonmac-SIG] Problem with iCal and appscript

[Paul Berkowitz]

On 4/17/04 7:51 PM, "Daniel Lord" <daniel at brightfire.org> wrote:

> HAS's appscript is a great achievement and very useful but I have
> noticed a problem on my system with the demo program from his site:
> 
>   the datetime object is shifted by -12 hours when added to iCal. The
> demo puts the entry "First pants, then shoes" in the Calendar on the
> 16th at 1200 rather than on the 17th, (presumably at 0000).
> I tried a few different configurations of dates and all were shifted by
> 12 hours
> 
> I am in PDT (GMT +8) so it isn't a UTC issue, otherwise the shift would
> be 8 not 12. I do use a 24-hour clock in my preferences and an
> international time/date setting and thought that may be the problem.
> But, setting the defaults didn't fix this. The Python datetime library
> seems to work correctly. This is with iCal 1.5.2. Perhaps something
> changed from version 1.0 that is interpreting the hour field
> differently? Anybody have an idea?

Yes. I've been applescripting iCal and it's rife with bugs. This one may be
related, although it appears not: I _have_ found the AppleScript bugs to be
GMT-related. (BTW, PDT is GMT - 7, not GMT + 8; GMT is not British Summer
Time. PST is GMT - 8.)

First of all, you have to make sure that iCal's preferences are set to Turn
On Time Zone support.

In AppleScript, the problem arises for events only for All-Day Events when
Time Zone support is On.

When _setting_ an all day event, you have to set the start time to the time
that, when converted to GMT, will be the actual time you want (always
00:00), PLUS a full extra day (!). So, in the summer months in California
(PDT), you first figure out you need 5 PM on the day before the real day,
then add a day to make it 5 PM on the day you want. However when you read it
back (get the start date) the result is 5 PM on the day before, NOT the day
of, the real start date you want. For end times, you both set and get the
time that, when converted to GMT, will be the actual time you want (no extra
day added). So if it's a one-day event, that's 5 PM on the day of the event,
in California (instead of 00:00 on the next day). I.e, when setting (making)
a new one-day, all-day event, you set both the start time and the end time
to the same 5 PM on the day of the event!  What a mess. Note that when
_getting_ an all day event, the 5 PM -on -preceding-day for each of start
time and end time is the result both if the event was made by AppleScript or
in the UI. 

For todos, it's even weirder: when making a new todo by script, you can set
the due date to the real time (always 00:00)and when you get it, it's also
OK. BUT, if you get the due date of a todo made in the UI, the time returned
is NOT the real date, but once again  5 PM on the day before the real day
(in California summer). So you have to expect either, check the time and add
7 or 8 hours, or whatever the difference is to GMT _at the time of the
todo_, not necessarily the difference from GMT on the day you run the
script, IF and only IF the time of the due date is not 00:00.

Furthermore you can't use whose filters (I believe has has an equivalent in
Python) on due dates - they don't work.

I've bugged all of these with Apple. God knows if they'll fix them for a
later release. They had a similar bug for birth date in Address Book Jaguar,
which I bugged, and they fixed it for Panther.

The bug you're reporting doesn't sound the same. I'd be very interested to
hear if you also hit these bugs: i.e. are the bugs in the AppleEvents, or
just in Apple's AppleScript implementation. I suspect the latter - the iApp
devs don't seem to know the first thing about AppleScript. The Cocoa APIs
usually work just fine. So likely the AppleEvents do too. But maybe not.

-- 
Paul Berkowitz