On Mon, 2011-12-12 at 12:47 -0800, walt wrote:
> I think (maybe) the problem is this commit from the bug you cited:
>
> http://git.gnome.org/browse/evolution/commit?id=44e007e1
>
> That commit puts an extra '&' in front of the date string for reasons
> I don't understand. Maybe that commit was really intended for an
> older branch of evolution?
Hi,
I do not understand that change too. Chen should know.
> In addition to the 'x' character you mention, the old way of calling
> the correct date is now required again, like this (please try it):
>
> $ evolution calendar:///?startdate=x20111225T120000Z [ThhmmssZ]
Works for me, the calendar is opened on December 25th, 2011.
> IIRC the original patch taught evolution to compensate for the users
> local time zone, so the calendar date always increments at midnight,
> local time.
>
> The alternate workaround was to force the time to be 12:00:00 Zulu
> (as in my example above) instead of the user's real time, which in
> practice has the same effect of incrementing the date by one.
This is not accurate. The convention for startdate/enddate parameters of
calendar:// is that the required times are always in UTC, thus they can
be properly translated to user's timezone set in evolution. Thus this is
not an "increment by one". The correct approach is to get the time you
want to see in evolution, convert it to UTC and with it call evolution.
If your timezone in evolution matches the one used in the application
you call evolution from, then you get the correct date, as expected.
Bye,
Milan
_______________________________________________
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-list
