| Scribe v2 Beta?
|
|---|
Date: 17/2/2008
| Well due to some timely feedback on the v2.00 alphas we might be approaching beta (as in all the functionality working again) sometime in the next week. I've crossed off all the bugs reported against alpha3 and made a release for alpha4.
Do what do you think? Any good?
|
| Comments:
|
exosceleton
18/02/2008 6:44am
| I see you implemented the timezone option field for creating calendar events.
Does this mean that i have to change the +1 it is now to +2 if i want to enter an event in june?
If so, i would love a "zulu" time option in that field, meaning that the time entered will always be the time shown, whatever happens to the system clock, or whether the event was shared across timezones. |
fret
19/02/2008 11:23pm
| I think that will be required by the iCal spec. A lot of what I do has to map onto the iCal file format so that import / export works. At this stage the timezone isn't hooked up to anything. But the plan is to make it work correctly at some point. Probably in v2 to be honest... it's a biggish fix with a lot of thinking and testing. And that makes it a pain to implement in 2 code bases (v1.xx and v2.xx are going to diverge). |
exosceleton
20/02/2008 7:44am
| iCal: yeah probably.
not hooked up: ok i'll just ignore it for now, and keep an eye out around daylight saving time day.
divergence: i can see you don't want that.
|
exosceleton
20/02/2008 10:19am
| from the IETF (linked from internetmailconsortion linked from memecode.com):
http://www.ietf.org/rfc/rfc2445.txt par 4.3.5 page 36.
parafrasing: if you do not include timezone info the time is treated as local, or floating.
FORM #1: DATE WITH LOCAL TIME
The date with local time form is simply a date-time value that does
not contain the UTC designator nor does it reference a time zone. For
example, the following represents Janurary 18, 1998, at 11 PM:
DTSTART:19980118T230000
Date-time values of this type are said to be "floating" and are not
bound to any time zone in particular. They are used to represent the
same hour, minute, and second value regardless of which time zone is
currently being observed. For example, an event can be defined that
indicates that an individual will be busy from 11:00 AM to 1:00 PM
every day, no matter which time zone the person is in. In these
cases, a local time can be specified. The recipient of an iCalendar
object with a property value consisting of a local time, without any
relative time zone information, SHOULD interpret the value as being
fixed to whatever time zone the ATTENDEE is in at any given moment.
This means that two ATTENDEEs, in different time zones, receiving the
same event definition as a floating time, may be participating in the
event at different actual times. Floating time SHOULD only be used
where that is the reasonable behavior.
In most cases, a fixed time is desired. To properly communicate a
fixed time in a property value, either UTC time or local time with
time zone reference MUST be specified.
The use of local time in a DATE-TIME value without the TZID property
parameter is to be interpreted as floating time, regardless of the
existence of "VTIMEZONE" calendar components in the iCalendar object.
|
exosceleton
20/02/2008 10:50am
| which interestingly enough is precisely the way inscribe is exporting at the moment, only with UTC time calculated from the user-entered time.
According to the same document you should use a Z at the end to indicate a UTC time.
DTSTART:20071227T093000Z
( i know this issue is not on your mind right now with all the v2 stuff, and i dont in any way expect you to proceed with this now. Just thought i'd do some research on my own that may be of use to you at some point) |
fret
20/02/2008 10:33pm
| DTSTART:20071227T093000Z
Yeah I had worked out that I was missing the "Z" recently. I don't think that it helps the situation where you have 2 timezones split across the one view. I'll have to know when DST starts and ends for the current user, there is no way around that. |
exosceleton
21/02/2008 3:09pm
| It does provide the possibility of entering the value "Z" in the "timezone" edit box you added.
It does not remove the need for the "timezone" editbox. |
exo
21/02/2008 4:56pm
| with z meaning zulu, or floating or whatever the user entered.
which is the DTSTAT value without Z.
|
|
|
| Reply
|
|---|
| From:
|
|
| Email (optional):
|
(Will be HTML encoded to evade harvesting)
|
| Message:
|
|
|
|
|
|
|
|
|
|
