[09:45:41] --- pigdog has joined
[09:47:48] <pigdog> Greetings. The Jabber Session will begin at 4:00pm CET / 3:00pm GMT / 10:00am EST / 7:00am PST
[09:58:49] --- bernard.desruisseaux has joined
[10:00:07] --- bernard.desruisseaux has left
[10:00:31] --- bdesruisseaux has joined
[10:00:41] <bdesruisseaux> Hello Eliot!
[10:00:53] <pigdog> hi bernard - waiting for others
[10:01:50] <pigdog> alexey will join us momentarily
[10:03:44] --- alexeymelnikov has joined
[10:04:20] <pigdog> greetings alexey
[10:04:26] <pigdog> will wait just another moment or two
[10:05:24] <alexeymelnikov> Hi everybody
[10:06:46] <pigdog> ok, let's start.
[10:06:55] <pigdog> agenda bashing:
[10:07:06] <pigdog> 1. Open 2445 issues
[10:07:09] <pigdog> 2. start down 2446
[10:07:17] <pigdog> 3. other business (one other thing)
[10:07:30] <pigdog> we are of course missing cyrus at this point and it would be helpful to have others here as well
[10:07:47] <alexeymelnikov> Yes, Cyrus would be useful for 2446 ;-)
[10:07:55] --- jonlennox has joined
[10:07:59] <pigdog> welcome john
[10:08:05] <pigdog> sorry s/h//
[10:08:14] <jonlennox> Hello! No problem
[10:08:18] <bdesruisseaux> Hi Jon
[10:08:20] <pigdog> can we first revisit briefly issue 8
[10:08:52] <pigdog> I recall this coming up repeatedly in multiple issues, and it goes right to the heart of the matter with regard to discontinuities that jon has raised
[10:09:09] <pigdog> Does P1D = 24 hours and is this stated in the ISO standard anywhere?
[10:09:52] <bdesruisseaux> ISO 8601 does say something... hold on
[10:10:07] <pigdog> (holding)
[10:10:24] <jonlennox> If ISO 8601 actually specifies semantics for duration fields, that could be very helpful...
[10:10:29] <bdesruisseaux> 2.1.7 nominal duration duration expressed amongst others in years, months, weeks or days NOTE The duration of a calendar year, a calendar month, a calendar week or a calendar day depends on its position in the calendar. Therefore, the exact duration of a nominal duration can only be evaluated if the duration of the calendar years, calendar months, calendar weeks or calendar days used are known.
[10:11:37] <bdesruisseaux> Also: 2.2.6 calendar day time interval starting at midnight and ending at the next midnight, the latter being also the starting instant of the next calendar day NOTE 1 A calendar day is often also referred to as day. NOTE 2 The duration of a calendar day is 24 hours; except if modified by: — the insertion or deletion of leap seconds, by decision of the International Earth Rotation Service (IERS), or — the insertion or deletion of other time intervals, as may be prescribed by local authorities to alter the time scale of local time.
[10:12:09] <pigdog> perfect.
[10:12:13] <jonlennox> Do they say further than that? Particularly the "P1DT8H" problem?
[10:12:59] <pigdog> jon perhaps, explain the problem?
[10:13:16] <bdesruisseaux> 8H + 1D != 1D + 8H ?
[10:13:32] <jonlennox> Does P1DT8H mean "add 1 nominal day (which might be 23 or 25 hours), then add 8 actual hours"?
[10:13:35] <jonlennox> B: exactly.
[10:14:46] <pigdog> the intuitive thing to me says that one must calculate 1D based on the moment it is to occur. is this not correct?
[10:15:02] --- apn has joined
[10:15:09] <pigdog> greetings aki!
[10:15:11] <apn> (Sorry, got tied up)
[10:15:18] <alexeymelnikov> Hi
[10:15:20] <pigdog> we're on our favorite subject
[10:15:21] <apn> Hi all!
[10:15:25] <bdesruisseaux> Hi Aki!
[10:16:11] <bdesruisseaux> ISO 8601 actually defines a "month" (M) duration which is even more confusing...
[10:16:40] <pigdog> i guess what i'm concluding, however, is that they've addressed the corner cases. is this not true?
[10:17:28] <jonlennox> If there's an implicit order (presumably largest-interval-first) to durations, "the instant the 1D is to occur" is well-defined.
[10:17:41] <jonlennox> But as Bernard said, you have to say whether you add the 1D first or the 8H first.
[10:17:43] <bdesruisseaux> 4.4.3 Duration 4.4.3.1 General Duration can be expressed by a combination of components with accurate duration (hour, minute and second) and components with nominal duration (year, month, week and day). The term duration will be used to designate expressions containing components with accurate duration, with nominal duration, or both.
[10:18:20] <jonlennox> Unless we want to just block mixing (I like these terms) accurate and nominal durations.
[10:18:26] <jonlennox> I guess they're ignoring leap-seconds, then?
[10:18:39] <pigdog> no- see above
[10:18:39] <jonlennox> Otherwise everything larger than seconds is technically nominal.
[10:19:08] <pigdog> from above: NOTE 2 The duration of a calendar day is 24 hours; except if modified by:— the insertion or deletion of leap seconds, by decision of the International Earth Rotation Service (IERS), or
[10:19:25] <jonlennox> Right, but that's inconsistent with the definition of hour and minute as accurate durations.
[10:19:48] <bdesruisseaux> Jon: Right.
[10:20:07] <pigdog> so - are leap seconds a problem we need to address?
[10:20:17] <jonlennox> No, I don't think so. I'm just being pedantic.
[10:20:28] <pigdog> ding ding. that's my word of the day "pedantic"
[10:20:29] <bdesruisseaux> Actually some people are pushing to get rid of the leap second...
[10:20:37] <jonlennox> I'd think that an ISO spec would need to address them, but if they don't, that's not our problem.
[10:20:59] <pigdog> ok, let's now dispose of issue 8. i believe two things need to be addressed
[10:21:07] <jonlennox> If we forbade the mixing of "nominal" and "accurate" durations, would it break anything?
[10:21:10] <pigdog> first, do we need to update the reference to the 2004 standard?
[10:21:28] <bdesruisseaux> I think we should update the reference.
[10:21:49] <pigdog> in that case, are there any incompatibilities introduced?
[10:22:02] <pigdog> (i will review both versions before signing off on this)
[10:22:05] <bdesruisseaux> I also want to clarify rfc2445bis to clarify that iCalendar is actually a subset of ISO8601
[10:22:38] <bdesruisseaux> For instance, ISO supported Years and Month durations... iCalendar does not (good!).
[10:23:41] <pigdog> i'm okay with that so long as this was the intent from the beginning
[10:23:45] <pigdog> (in 2445)
[10:24:00] <bdesruisseaux> I believe I should also talk of "accurate" and "nominal" duration in the section about the DURATION value type.
[10:24:02] <pigdog> and so far as i can tell that's true
[10:25:41] <jonlennox> There's also the question of whether DTEND and DURATION are equivalent or not -- do we have an issue in the tracker for that?
[10:25:44] <pigdog> so, given that, the proposal on the floor is to use the word subset of 8601(2004), provide a brief discussion of what happens when DST transitions occur. who agreess with that?
[10:25:58] <pigdog> wiat
[10:25:59] <pigdog> wait
[10:26:20] <pigdog> and what happens is that P1D might equal 23 or 25 hours
[10:26:30] <jonlennox> We need to either define or forbid P1DT8H.
[10:27:17] <pigdog> if it is already defined in the 8601, we should simply reference that document
[10:27:35] <jonlennox> Bernard: is it? As in, does it say "do nominal math first"?
[10:27:38] <pigdog> otherwise we have multiple standards covering the same ground
[10:28:24] <jonlennox> I agree, but given that 8601 isn't freely available, we should reiterate whatever it says.
[10:28:45] <bdesruisseaux> I'm not sure all this is clearly defined in ISO...
[10:29:03] <pigdog> much as i'd like to that just invites trouble with regard to interpretation. so then should we define OR forbid?
[10:29:11] <jonlennox> Does anyone actually generate mixed nominal and accurate durations?
[10:29:12] <pigdog> my preference would be for the latter
[10:29:33] <pigdog> what do people think?
[10:29:44] <bdesruisseaux> Forbidding might break compatibility...
[10:29:48] <jonlennox> I'd be inclined to forbid unless it's actually in-use in the wild.
[10:30:00] <pigdog> i just can't imagine it in use
[10:30:02] <jonlennox> That's the point of calsify, after all -- remove the confusing corner cases that no one uses.
[10:30:03] <bdesruisseaux> That being said Microsoft Outlook provides absolutely no support for the DURATION property!
[10:31:04] <pigdog> does anyone object to the above proposal? speak now. i believe this will settle issue 8 + all the discontinuity issues
[10:31:16] <jonlennox> It doesn't settle all of them.
[10:31:34] <bdesruisseaux> Sorry it's not clear to me what is the proposal...
[10:31:42] <pigdog> the proposal is as follows:
[10:31:51] <pigdog> 1. update reference to subset of 8601(2004)
[10:32:39] <pigdog> 2. provide example crossing DST or state clearly that P1D != 24H
[10:33:03] <pigdog> 3. Forbid P1DT8H
[10:33:16] <pigdog> in thinking about it i don't think we need to forbid 3
[10:33:19] <pigdog> but i buy 1 and 2
[10:33:53] <jonlennox> If we don't forbid 3, we need to state clearly that you do the nominal duration first, then the accurate duration.
[10:33:55] <bdesruisseaux> #1 -- Yes. That was on my to-do list. #2 -- Was partially clarified with issue 27.
[10:34:14] <pigdog> agree with state clearly
[10:34:15] <bdesruisseaux> #3 -- I would rather not forbid
[10:34:22] <pigdog> so let's state clearly
[10:34:25] <pigdog> fair?
[10:34:27] <bdesruisseaux> Yes.
[10:34:27] <jonlennox> There's also the question of what happens if a nominal duration would put you into a discontinuity.
[10:34:57] <pigdog> i believe this brings us to one of the other issues, right?
[10:35:26] <jonlennox> probably. They're all mixed up together.
[10:36:08] <pigdog> ok, let's go there
[10:36:58] <pigdog> issue 78
[10:37:03] <pigdog> sorry no
[10:37:32] <pigdog> 68
[10:38:09] <jonlennox> One sec
[10:38:32] <pigdog> http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue68
[10:39:19] <apn> BTW, ISO 8601 is available for download from iso.org
[10:39:27] <pigdog> (for a price)
[10:40:04] <pigdog> so let's take each of these in turn. there are actually two issues in 68
[10:40:28] <bdesruisseaux> The proposal for issue 68 is to forbid date-time values that occur twice or don't exist.
[10:40:34] <pigdog> first, under the "do not hit your head against the wall" rule, don't schedule anything on a non-existant time, according to the VTIMEZONE rule
[10:41:07] <bdesruisseaux> We can't forbid DATE-TIME values that don't exist everywhere in iCalendar...
[10:41:40] <bdesruisseaux> By definition a VTIMEZONE expect you to specify a DATE-TIME value that does not exist!
[10:42:09] <pigdog> right. i'm referring to VEVENTs, VTODOs, etc.
[10:42:49] <pigdog> so are we agreed on that part?
[10:43:12] <bdesruisseaux> I'm not convinced
[10:43:19] <jonlennox> It does mean that if you're editing an event's VTIMEZONE definition, you need to check for this.
[10:43:50] <pigdog> jon, you mean in the VEVENTs and VTODOs you've created?
[10:44:06] <jonlennox> Yes
[10:44:28] <pigdog> so bernard, under what circumstance would you want to specify a non-existant moment? ;-)
[10:44:57] <bdesruisseaux> Me? Never! I sleep at that time of the day!
[10:45:12] <jonlennox> I.e. you had an event that was scheduled for 2:30 a.m. America/New_York on March 11, and then you updated to the new DST rules.
[10:45:13] <bdesruisseaux> Seriously, I guess the issue comes with recurring components
[10:45:45] <jonlennox> Now, to be sure, you'd need human intervention for the "what did you mean" here, but the client needs to be aware that it needs to ask the human.
[10:46:08] <pigdog> right. so what happens if we have a WEEKLY occurrence at 2:30am that crosses a DST transition?
[10:46:58] <bdesruisseaux> First, I would want a recurrence instance to occur not matter what...
[10:47:23] <bdesruisseaux> Now, the question is when exactly... 2:30 AM does not exist here...
[10:47:45] <pigdog> right. this requires human intervention.
[10:48:15] <bdesruisseaux> Using the UTC-OFFSET that was in effect before the current observance should do the trick here... No?
[10:48:51] <pigdog> does it, today?
[10:49:04] <jonlennox> What definition of "crosses a DST transition" are we using here?
[10:49:29] <bdesruisseaux> I was assuming the following sequence 01:59:59 03:00:00
[10:49:35] <pigdog> right
[10:49:49] <jonlennox> There are four (related) cases: DTSTART before, DTEND (or DTSTART+DURATION) after; DTSTART before, DTEND within; DTSTART within, DTEND after; both DTSTART and DTEND within.
[10:50:11] <pigdog> no.
[10:50:23] <pigdog> DTSTART+duration is probably clear for durations < 1 day
[10:50:34] <pigdog> if DTSTART is before, that is
[10:50:38] <jonlennox> Accurate durations, right.
[10:51:41] <pigdog> so our choices are either to alert the user or to use the offset prior to transition, right?
[10:52:21] <jonlennox> For which?
[10:52:32] <bdesruisseaux> In the case of a time that does not exist
[10:52:36] <pigdog> for any of these cases
[10:53:30] <pigdog> if these are our choices, and if we cannot decide now which is the best one, we will poll the WG on email to conclude the answer. fair?
[10:53:33] <jonlennox> If DTSTART is a non-existant 2:30, and DTEND is existant 3:15, if you use "offset before" you get DTEND < DTSTART.
[10:54:14] <pigdog> right. that leads me to the "alert the user" approach
[10:54:42] <jonlennox> I'm all in favor of "alert the user", but is that the same as "do not generate, any iCalendar document containing these is ill-formed"?
[10:54:53] <jonlennox> Because if not, we still need to describe how to interpret them.
[10:55:07] <pigdog> no, i think it is the same as "do not generate"
[10:55:15] <pigdog> or at least it should be
[10:56:05] <pigdog> ok, given the quiet i guess we're polling the WG.
[10:56:12] <pigdog> jon, with your permission, i'll use your examples
[10:56:48] <jonlennox> The proposal is: "if the start time of a recurring time would fall into a non-existant or repeated time, the result is undefined"?
[10:57:14] <jonlennox> (Or an end-time based on nominal duration)
[10:57:16] <pigdog> i think the proposal is "do not generate and alert the user"
[10:57:31] <pigdog> OR undefined
[10:57:35] <pigdog> those are the choices
[10:57:42] <bdesruisseaux> How about the same approache that was used previously...
[10:57:44] <jonlennox> I think those ar ethe same thing
[10:58:01] <pigdog> which is/
[10:58:02] <pigdog> ?
[10:58:06] <jonlennox> As a generator, do not generate and alert the user, because for a receiver they're undefined.
[10:58:16] <bdesruisseaux> You SHOULD NOT specify a time that does not exist or occur twice (expect for VTIMEZONE) If you do... the behavior is undefined.
[10:58:27] <jonlennox> Exactly.
[10:58:39] <pigdog> section, please?
[10:59:07] <bdesruisseaux> Euh... in the DATE-TIME value type section I guess ?
[10:59:20] <jonlennox> Well, this needs to apply to recurrences as well as DATE-TIMEs.
[10:59:31] <jonlennox> Maybe it needs to be in both places.
[10:59:47] <bdesruisseaux> I guess
[10:59:51] <pigdog> currently i don't see it in there at all
[11:00:00] <bdesruisseaux> :-)
[11:00:07] <bdesruisseaux> I'm proposing something that isn't there
[11:00:34] <pigdog> ok, if you are both agreed, let's get that out to the list.
[11:00:48] <pigdog> in the tracker, "bernard to add that text."
[11:01:17] <bdesruisseaux> In the real life (uh?) if Jon was to send me an email with such date-time values... I would get back to him to ask for clarifications...
[11:01:57] --- pigdog has left
[11:02:19] <apn> Uh-oh, Eliot disappeared...
[11:02:48] --- pigdog has joined
[11:03:08] <apn> Ah, here he is ;)
[11:03:47] <pigdog> so, now we have proposed text, right?
[11:03:48] --- bernard.desruisseaux has joined
[11:04:17] <bdesruisseaux> sorry I lost my connection...
[11:04:21] <jonlennox> We have a proposal; I don't think we have actual text for it.
[11:04:38] <pigdog> You SHOULD NOT specify a time that does not exist or occur twice (expect for VTIMEZONE)If you do... the behavior is undefined.
[11:04:46] <pigdog> or words very close to that effect
[11:04:52] <bernard.desruisseaux> right
[11:04:55] --- bdesruisseaux has left
[11:05:00] <jonlennox> The tricky word there is "specify".
[11:05:09] <pigdog> why?
[11:05:10] <apn> But what does the receiver do, can we leave it at "undefined"?
[11:05:26] <pigdog> that's the SHOULD NOT part, right?
[11:05:45] <jonlennox> It includes a) the value of a DATE-TIME, b) the recurrence of a event, and c) a or b plus a nominal duration.
[11:05:45] <pigdog> the receiver will probably have to either have some logic or hand it to the user...
[11:06:18] <apn> s/specify/generate ?
[11:06:22] <bernard.desruisseaux> or the receiver will hand the ambiguous value to its underlyling calendar library ... and ignore the issue!
[11:06:33] <bernard.desruisseaux> yes : generate
[11:06:35] <pigdog> ;-)
[11:06:48] <jonlennox> And if the underlying library makes demons fly out your nose, well, that's what "undefined" means.
[11:06:49] <apn> And what does the library.. oh never mind.. ;)
[11:07:00] <bernard.desruisseaux> Jon: You got it!
[11:07:20] <pigdog> ok... moving on
[11:07:31] <pigdog> (just one sec)
[11:07:32] <bernard.desruisseaux> There is a reason why DST shift occurs in the middle of the night after all...
[11:07:43] <pigdog> for some value of "middle of the night"
[11:08:25] <apn> Middle of the night for you is when I have breakfast :)
[11:08:52] <pigdog> Issue 69, please
[11:09:27] <pigdog> same resolution?
[11:10:34] <jonlennox> Yes, I think so.
[11:10:51] <bernard.desruisseaux> Probably.
[11:11:03] <pigdog> can i indicate that in the tracker?
[11:11:42] <pigdog> bernard?
[11:11:43] <bernard.desruisseaux> To be safe an application should either specify an EXDATE for the ambiguous instance and add an RDATE in UTC... or else specify an overriden components with a RECURRENCE-ID with the ambiguous value and a DTSTART in UTC... Ouf
[11:12:11] <jonlennox> That implies you can specify an EXDATE for an ambiguous time?
[11:12:48] <bernard.desruisseaux> I guess so
[11:12:55] <jonlennox> Wacky.
[11:13:10] <bernard.desruisseaux> but there is no ambiguity here right!
[11:13:19] <pigdog> right. the EXDATE is merely used as an index.
[11:13:37] <bernard.desruisseaux> You have two ambiguous values that matches...
[11:13:43] <pigdog> so.. SHOULD NOT + Bernard's text?
[11:14:03] <bernard.desruisseaux> Unless the two values were fed into a calendar library with a random behavior for such values !
[11:14:53] <pigdog> i'm sorry- you have two ambiguous values?
[11:15:04] <jonlennox> Certainly localtime() will return failure for a non-existent time on some libc's.
[11:15:15] <jonlennox> An event that occurs at 2:15 am and 2:30 am every time.
[11:15:19] <jonlennox> Every day, I mean.
[11:15:41] <pigdog> right, but as far as the ical library is concerned it's an index, right?
[11:15:49] <bernard.desruisseaux> Eliot: Right.
[11:16:02] <pigdog> ok, so that brings me back to SHOULD NOT + Bernard's text?
[11:17:03] <bernard.desruisseaux> Which imply that you SHOULD NOT generate iCalendar object with DATE-TIME values that don't exists... expect in VTIMEZONE compoenents and in the EXDATE property!
[11:17:29] <pigdog> *yes*
[11:17:53] <pigdog> jon?
[11:18:04] <bernard.desruisseaux> And given that the UNTIL rule part is required to be a DATE or DATE-TIME in UTC we don't really need to worry about it...
[11:18:13] <jonlennox> I think that makes some sense.
[11:18:34] <bernard.desruisseaux> Although it becomes fun to figure what should be the value of UNTIL in UTC that would actually match the last recurrence instance in the set... eheh!
[11:18:34] <jonlennox> I'm just concerned about how, as a library, I corrolate those EXDATEs.
[11:19:09] <bernard.desruisseaux> Different applications could end up with different number of recurrence instances !!! Bad ... very bad
[11:19:20] <jonlennox> I mean, if you SHOULD NOT generate an RRULE that hits those ambiguous times, what would the EXDATE be referencing?
[11:20:12] <bernard.desruisseaux> Do we really want the SHOULD NOT... for RRULE ? I guess that's the question
[11:20:24] <jonlennox> It'd certainly make things simpler.
[11:20:33] <jonlennox> The question is if it's overly restrictive.
[11:20:57] <pigdog> so what happens here from a user perspective? is it the intuitive thing?
[11:21:26] <pigdog> you exclude the instance but then need to have another event to indicate the right time?
[11:21:58] <bernard.desruisseaux> yes... but are we okay with the fact that an application MAY generate such a RRULE ?
[11:22:16] <bernard.desruisseaux> Or do we want to specify that an application SHOULD NOT do that.??
[11:22:26] <pigdog> what's the alternative?
[11:22:44] <jonlennox> The alternative to SHOULD NOT generate is specifying what it means.
[11:22:47] <bernard.desruisseaux> While I'm okay to say you SHOULD NOT specify explicitly a DATE-TIME value that occurs twice or does not occur...
[11:22:53] <jonlennox> Which is where we always run into the weeds.
[11:22:57] <bernard.desruisseaux> I'm less sure that we should say the same for RRULE...
[11:23:37] <bernard.desruisseaux> For RRULE we could say that the application really SHOULD clarify with either an EXDATE + RDATE in UTC... or with an overriden component RECURRENCE-ID + DTSTART in UTC
[11:24:11] <pigdog> why not?
[11:24:29] <bernard.desruisseaux> why not what? sorry...
[11:24:37] <pigdog> why not go with your text
[11:24:50] <jonlennox> Bernard: and if they don't?
[11:25:03] <pigdog> undefined again?
[11:25:10] <bernard.desruisseaux> Demons flies...
[11:25:10] <jonlennox> I'd weaken to "unspecified"?
[11:25:29] <pigdog> difference?
[11:25:31] <jonlennox> I.e. it occurs exactly once (for COUNT and BYSETBOS's sake) but exactly when is unclear.
[11:26:02] <pigdog> so exactly when it occurs is undefined
[11:26:13] <pigdog> ?
[11:26:21] <jonlennox> Yes, but you don't get demons.
[11:26:37] <pigdog> bernard?
[11:26:45] <bernard.desruisseaux> I lost you
[11:26:46] <bernard.desruisseaux> sorry
[11:26:47] <jonlennox> I.e. you're still in a sensible state, and EXDATE has something to apply to.
[11:27:33] <bernard.desruisseaux> Let me try to summarize where I am now...
[11:27:44] <jonlennox> So what a recurrence that would land at 20070311T023000 means is unclear, but EXDATE will indeed remove it.
[11:27:51] <pigdog> so- your text + SHOULD NOT generate + exact time in RRULE is undefined if you do
[11:28:32] <pigdog> ?
[11:28:38] <jonlennox> SHOULD NOT generate without appropriate EXDATE (or EXRULE? have we killed EXRULE?)
[11:28:49] <pigdog> EXRULE is no more
[11:28:53] <jonlennox> Okay.
[11:28:53] <apn> We have
[11:29:11] <jonlennox> Obviously you can't fix every instance of an open-ended recurrence, then.
[11:29:39] <pigdog> right - that poses a problem for perpetual events
[11:29:50] <bernard.desruisseaux> An application MAY generate an iCalendar object with an RRULE that will generate an ambiguous DATE-TIME value (occurs twice or none), *but* if it does it SHOULD specify an EXDATE for this recurrence instance + RDATE (or overridden instance / RECURRENCE-ID + DTSTART) else UNDEFINED. In addition to all that, if the ambiguous instance happens to be the last recurrence instance of the set ... the RRULE SHOULD NOT specify an UNTIL rule part... use COUNT instead.
[11:30:15] <jonlennox> Bernard: I don't see why UNTIL is a problem -- it's required to always be UTC.
[11:30:37] <jonlennox> Or are you concerned as to whether the final event triggers or not?
[11:31:22] <bernard.desruisseaux> UNTIL is not ambiguous itself... it is the UTC time of the last recurrence instance... that some applications may end up computing differently
[11:31:50] <bernard.desruisseaux> Some applications will discard it because it is after the UNTIL... some will keep it if it less or equal to UNTIL...
[11:31:52] <bernard.desruisseaux> RIght?
[11:32:07] <jonlennox> Does the UNTIL actually have to *be* the last recurrence instance, or just a time after the last one and before the one before that?
[11:32:14] <jonlennox> Er, after that?
[11:32:43] <bernard.desruisseaux> It does not need to be synchronized with a recurrence instance start time.
[11:32:47] <jonlennox> You could just put the UNTIL after the last of the ambiguous possibilities of the set.
[11:33:02] <bernard.desruisseaux> Yes. That would work.
[11:33:19] <pigdog> ok guys. we've run out of time. run with until. bernard, can you send this proposal to the list?
[11:33:48] <bernard.desruisseaux> Humm... Jon? Could you follow up on the mailing list?
[11:33:55] <jonlennox> On which point?
[11:34:00] <bernard.desruisseaux> I want to focus on the other issues... and get draft -06 OUT!
[11:34:25] <pigdog> exact wording based on this discussion
[11:34:36] <jonlennox> Okay.
[11:34:36] <bernard.desruisseaux> For issues 68 and 69.
[11:34:44] <pigdog> ok, thanks all!
[11:34:49] <apn> Meta-comment: seems to me we're now in the 20% of the 20/80 rule.
[11:34:51] <pigdog> oh wait!
[11:34:54] <apn> :)
[11:34:58] <pigdog> Alexey:
[11:35:17] <pigdog> Happy birthday to you, happy birthday to you, happy Birthday, Alexey, Happy birthday to you....
[11:35:26] <bernard.desruisseaux> Happy birthday to you, happy birthday to you, happy Birthday, Alexey, Happy birthday to you....
[11:35:27] <pigdog> ciao!
[11:35:47] --- pigdog has left
[11:35:48] <apn> See ya!
[11:35:52] --- apn has left
[11:37:11] <alexeymelnikov> Thanks :-)
[11:37:37] --- alexeymelnikov has left
[12:29:19] --- jonlennox has left
[16:30:10] --- bernard.desruisseaux has left: Logged out