[09:45:23] --- pigdog has joined
[10:01:08] --- bdesruisseaux has joined
[10:01:16] <bdesruisseaux> Hi Eliot
[10:03:15] --- cyrus_daboo has joined
[10:04:09] <bdesruisseaux> Eliot (pigdog) is in the room, but his actually having problems...
[10:10:28] <cyrus_daboo> Hello?
[10:10:29] --- Eliot has joined
[10:10:47] <cyrus_daboo> Anyone there?
[10:10:52] <Eliot> hello
[10:10:53] <bdesruisseaux> I'm here
[10:11:00] <Eliot> anyone else?
[10:11:02] <cyrus_daboo> OK!
[10:11:15] <Eliot> for whatever reason i can't see who's online
[10:11:30] <Eliot> i see messages from cyrus and from bernard. is anyone else online?
[10:11:35] <bdesruisseaux> No.
[10:12:00] <Eliot> ok. we'll start in just a moment. apoligies for the delay
[10:12:07] <cyrus_daboo> I don't see anyone else in my list, but Eliot shows up twice once as 'Eliot' and once as 'pigdog'.
[10:12:26] <Eliot> ok, now i see myself
[10:12:29] <cyrus_daboo> Actually three times - there is also an inactive gmail.com entry!
[10:12:29] <Eliot> but nobody else
[10:12:52] <Eliot> well, now i really can talk out of both
[10:13:06] <Eliot> oh something is really screwed up
[10:13:26] <Eliot> ok, let's try to proceed
[10:13:48] <Eliot> agenda bashing:
[10:13:55] <Eliot> ietf, open issues
[10:14:04] <Eliot> anything else?
[10:14:18] <Eliot> still there?
[10:14:24] <bdesruisseaux> quorum
[10:14:32] <Eliot> ok..
[10:14:34] <cyrus_daboo> Ok
[10:14:35] <bdesruisseaux> Are we enough?
[10:14:41] <Eliot> three people is a bit small
[10:14:48] <Eliot> but let's talk about the ietf even so
[10:15:03] <Eliot> to start, we still have enough issues that we'll need to discuss RFC 2445,
[10:15:04] <Eliot> bis
[10:15:15] <Eliot> i hope to have them all but done but we're still not there
[10:15:34] <Eliot> once that is done, cyrus, i suspect that we will have to channel you with jabber
[10:15:40] <Eliot> i hope it works better thant oday
[10:15:49] <Eliot> we can try iChatting voice
[10:15:51] --- jonlennox has joined
[10:15:54] <Eliot> with a microphone
[10:16:00] <Eliot> hello jon
[10:16:27] <jonlennox> Good morning!
[10:16:35] <Eliot> i will be sending out a note requesting iTIP issues today
[10:16:49] <Eliot> we won't close that list until well after the IETf, though
[10:17:02] <Eliot> does this sound reasonable?
[10:17:22] <cyrus_daboo> Yes.
[10:17:26] <Eliot> ok
[10:17:38] <bdesruisseaux> yes
[10:17:38] <Eliot> then please look for a message.
[10:18:11] <bdesruisseaux> I don't think we can actually review the draft and find all open issues at once...
[10:18:28] <bdesruisseaux> As we will discuss open issues... only then will more issues be found!
[10:18:34] <Eliot> right -;
[10:19:02] <Eliot> ok, i'm ready to proceed to open issues
[10:19:19] <Eliot> i would like to start with issues, 8, 68, and 69
[10:19:42] <Eliot> did everyone see johnathan's message?
[10:19:58] <Eliot> sorry s/john/jon/
[10:20:16] <bdesruisseaux> I saw them, but I haven't had time to go over them ... sorry
[10:20:29] <Eliot> please take a moment now.
[10:20:44] <bdesruisseaux> I've had discussions with other folks around here on the subject though
[10:21:01] <Eliot> ok..
[10:21:29] <bdesruisseaux> Comments I got was... Why can't you specify 1 behavior for times that occur twice or does not exist...
[10:21:41] <bdesruisseaux> Instead of leaving the behavior undefined...
[10:22:11] <Eliot> is there a sane recommendation for that?
[10:22:19] <bdesruisseaux> For instance, for a date-time that occurs twice... pick the first instance ... that's it.
[10:22:41] <bdesruisseaux> Jon... Any use cases for why that would be a bad idea?
[10:23:21] <jonlennox> The only question is whether most calendar libraries make it easy to figure this out.
[10:23:48] <cyrus_daboo> Its a bad idea in that there is a whole hour that can no longer be used in a DTSTART or DTEND - unless you fall back to UTC - we always have that option to resolve these conflicts.
[10:24:40] <jonlennox> Does the ISO spec say anything about ambiguous times?
[10:25:15] <bdesruisseaux> I haven't review the ISO spec yet.
[10:25:25] <bdesruisseaux> Cyrus: Can you please clarify?
[10:26:02] <cyrus_daboo> When 2.30 am occurs twice when the clocks go back, if you always pick the first one, how can you start an event on the second one?
[10:26:20] <cyrus_daboo> (Probably should ne 1.30 am BTW).
[10:27:19] <cyrus_daboo> This is an important issue for any "fixed" schedules - e.g. in the airline industry.
[10:27:58] <Eliot> but i would imagine they keep their schedules in UTC, no?
[10:28:12] <bdesruisseaux> The answer would be YOU CAN'T if you specify such a time... because it would always means the first occurence...
[10:28:41] <cyrus_daboo> But you can always generate a component using UTC that gives you the exact one you want - be it a single instance event of recurring event. The recurring one is harder of course when it is unbounded as you have no knowledge of future TZ changes.
[10:28:57] --- alexeymelnikov has joined
[10:29:13] <Eliot> interestingly there was an article about this in the wsj, either yesterday or today, about how all the connections are getting tighter.
[10:29:30] <Eliot> in point of fact, now that i remember, the airlines must keep to local schedules for landing slots, amongst other things
[10:29:34] <cyrus_daboo> So, if you strictly follow the VTIMEZONE onset rules etc, will you always pick the first one?
[10:30:20] <bdesruisseaux> Not sure what you mean here
[10:30:25] <cyrus_daboo> I think you will if you sort by onset time and pick the last observations less than the time you are interested in.
[10:30:46] <bdesruisseaux> VTIMEZONE have no ambiguity... They typically specify a time that does not exists... but when you consider TZOFFSETFROM you get a valid UTC time...
[10:31:35] <Eliot> so coming back to jon's proposal?
[10:31:42] <Eliot> (hi alexey)
[10:32:07] <bdesruisseaux> I've lost track of Jon's proposal!@
[10:32:12] <cyrus_daboo> The question is given a local time, how do I convert it to UTC? If the local time is 1.30 am during a "clocks go back" time, then you would find the TZOFFSET for the earlier observance (the one before the change) if you see that the next change is 2.00 am.
[10:32:17] <jonlennox> Ambiguous times are unspecified.
[10:32:43] <jonlennox> (That was my proposal)
[10:33:11] <bdesruisseaux> I'm not happy with "Calendar generators MUST NOT generate DATE-TIME values that are non-existent or ambiguous"
[10:33:18] <bdesruisseaux> I don't believe it is the rigth approach....
[10:33:23] <cyrus_daboo> But we should give guidance to clients as to what to do in such cases.
[10:33:29] <bdesruisseaux> We are putting the burden on the client to check that...
[10:33:33] <jonlennox> We'd need to specify how they're interpreted, then.
[10:33:45] <bdesruisseaux> plus a VTIMEZONE could change... and then you need to face the situatino anyway...
[10:33:55] <bdesruisseaux> Plus you will have the problem with RRULE also...
[10:34:09] <bdesruisseaux> Yes. We need to pick!
[10:34:14] <Eliot> but the objects are self-consistent, so what does a VTIMEZONE change mean?
[10:34:44] <bdesruisseaux> Yes, the object are self-consistent... but !
[10:34:52] <jonlennox> Is "pick the first instance if ambiguous, pick the first instant afterwards if non-existant" a good enough rule?
[10:35:15] <bdesruisseaux> When you import the object in a system... it is most likely going to get ride of the VTIMEZONE.. since it will have match it with one of its internal time zone definition...
[10:35:23] <jonlennox> It's the second point that I think would be especially hard to get many calendar libraries to calculate for you.
[10:35:30] <bdesruisseaux> when the internal time zone definition changes ... you have the problem
[10:35:42] <cyrus_daboo> Simple rule: if a local time occurs twice, pick the one with the earliest UTC time, if a local time does not exist, use the first localtime following that does exist.
[10:36:34] <bdesruisseaux> I don't like Cyrus proposal for date-time that don't exist...
[10:36:36] <Eliot> cyrus, i would be fine with that with one adendum... you cannot have two recurrences of the same event at the same time
[10:36:46] <jonlennox> I have no idea how you'd calculate the latter from (e.g.) mktime() other than by binary search.
[10:36:53] <jonlennox> Bernard: what would you pick instead?
[10:36:56] <cyrus_daboo> Actually the choice of pick earliest/latest may depend on whether you are talking about DTSTART or DTEND.
[10:37:28] <Eliot> why?
[10:37:33] <bdesruisseaux> I would find the previous time that did existed... find the UTC offset for it... and use the same UTC offset with the local date-time that didn't exist to figure its UTC time.
[10:37:46] <cyrus_daboo> I think the policy we should have is to make sure someone cannot miss a meeting. So we pick the earlier time for DTSTART (even for non-existent case). Then we could pick the later time for DTEND - though that may be less important.
[10:38:02] <jonlennox> Bernard: this can lead to end times after start times, though.
[10:38:19] <jonlennox> An event that goes from 2:50 am to 3:15 am, e.g.
[10:39:39] <Eliot> ok, i'm still not seeing consensus. worse- i now see three proposals - sort of
[10:39:57] <bdesruisseaux> Jon: You are right.
[10:40:28] <bdesruisseaux> Date-time that do not exist are harder to handle
[10:40:47] <Eliot> cyrus, do you want to write up your counter proposal? jon will you be joining us in prague?
[10:41:02] <bdesruisseaux> The problem here is that DTSTART does not exist, while DTEND does...
[10:41:15] <jonlennox> I will be in Prague, but I have to be at the MMusic meeting during the timeslot of Calsify.
[10:41:24] <jonlennox> If I remember the agenda properly.
[10:41:42] <Eliot> this was cyrus' point. that DTSTART and DTEND may require different treatment
[10:42:00] <jonlennox> Oh, no, Calsify moved...I think it'll be okay.
[10:42:21] <jonlennox> Eliot: this is a different case of different treatment, though.
[10:42:31] <jonlennox> This is a case where DTEND is not (itself) ambiguous.
[10:43:22] <Eliot> and the case where DTSTART is
[10:43:28] <jonlennox> Right.
[10:43:34] <cyrus_daboo> So if the rule is move DTSTART earlier, move DTEND later, and we start with DTSTART<DTEND, we should always end up with DTSTART<DTEND no matter what the initial values are, correct?\
[10:43:34] <bdesruisseaux> Would we want to go into more details and specify that if DTEND ends up being earlier in time than DTSTART... the same UTC Offset that was used for DTSTART should be used??
[10:44:17] <bdesruisseaux> How do you more a DTSTART value that does not exist earlier?
[10:44:22] <cyrus_daboo> I have no problem with moving DTEND later.
[10:44:37] <Eliot> we have two separate problems - when does the event start and how long does it last? if one is non-ambiguous perhaps the rule should be to calculate a duration from a previous recurrence?
[10:44:45] <cyrus_daboo> You pick the the localtime just prior to it that does exist.
[10:45:01] <jonlennox> The worry is an event from 2007-03-11 02:45:00 (doesn't exist) to 2007-03-11 03:15:00 (does).
[10:45:24] <Eliot> right. so what was the duration from the previous recurrence?
[10:45:38] <Eliot> figure it out and apply to determine DTSTART?
[10:45:52] <Eliot> ?
[10:45:56] <jonlennox> Let's say this is an explicit DTSTART/DTEND pair.
[10:46:17] <jonlennox> Otherwise our defined dtend-dtstart semantics apply.
[10:46:18] <Eliot> ok..
[10:46:22] <cyrus_daboo> So that would become 2007-03-11 02:00:00 to 03:15:00.
[10:46:42] <jonlennox> Do you mean 2007-03-11 03:00:00?
[10:46:52] <bdesruisseaux> The problem here is that most likely the intent is not the end the meeting at 3:15:00 but really 4:15:00 !
[10:47:24] <jonlennox> I don't think it's in general possible to infer intention here.
[10:47:39] <bdesruisseaux> Jon: I agree !
[10:47:44] <Eliot> ok, then you've got to throw an error.
[10:48:00] <bdesruisseaux> Cyrus: 2:00:00 does not exist here... Did you mean 01:59:59 ?
[10:48:01] <jonlennox> We need unambiguous rules, and then guidance for generators to ask for human intervention in the cases when the rules might do something surprising.
[10:48:40] <cyrus_daboo> Yes you could use 1:59:59.
[10:48:46] <bdesruisseaux> Can we go over some use cases (like the one Jon just mentionned) and try to figure what makes sense?
[10:49:07] <jonlennox> I'd be inclined to pick 3:00:00 instead, because otherwise you're picking something like 1:59:59.99999....
[10:49:59] <jonlennox> The problem is that it's hard to get calendar libraries to calculate this for you. mktime(), for instance, either follows something kind of like Bernard's rule, or returns an error, for a non-existent time.
[10:50:10] <jonlennox> Depending on your libc.
[10:50:37] <bdesruisseaux> Humm...
[10:51:03] <bdesruisseaux> But you shouldn't be using the libc to handle time zone stuff...
[10:51:17] <cyrus_daboo> That's an implementation detail. If we pick the one true way to do it, the libraries should follow over time...
[10:51:21] <bdesruisseaux> The time zone info was provided in the VTIMEZONE object...
[10:51:23] <Eliot> guys - i think bernard wanted to cover some other issues. if we're not able to close, can we make this first order of business at the face 2 face?
[10:51:23] <jonlennox> True.
[10:51:37] <jonlennox> Okay
[10:51:38] <cyrus_daboo> Ok - move on.
[10:51:49] <bdesruisseaux> THANKS!
[10:51:54] <cyrus_daboo> Actually can we discuss this on Sunday morning at 2:15 am EST?
[10:51:57] <bdesruisseaux> Beside it will be more fun face to face ;-)
[10:51:59] <cyrus_daboo> :-)
[10:52:19] <Eliot> ok, let me just implore you all to be prepared to resolve this in prague so we can close all issues and move on.
[10:52:19] <bdesruisseaux> Cyurs I'll call you home!
[10:52:23] <Eliot> speaking of which
[10:52:42] <Eliot> bernard you mentioned two issues to me that you specifically wanted to address
[10:52:49] <bdesruisseaux> 63 and 79
[10:52:56] <Eliot> can we proceed to issue 63?
[10:53:51] <cyrus_daboo> OK, well there was some puch back on the list for RDATE<DTSTART.
[10:54:00] <cyrus_daboo> s/puch/push/
[10:54:25] <Eliot> right. is there a use case where that it makes sense for RDATE < DTSTART?
[10:54:32] <bdesruisseaux> I think so.
[10:54:52] <jonlennox> Since DTSTART determines the RRULE.
[10:55:06] <bdesruisseaux> You want to had an instance to a recurring component... why shouldn't you be allowed to add a date that occured before DTSTART?
[10:55:24] <cyrus_daboo> Given that we now reaquire DTSTART to match the first instance of an RRULE, if you want a recurring meeting where the "kick-off" meeting is an "exception", then you have to use an RDATE earlier than DTSTART.
[10:55:28] <bdesruisseaux> You can't simply change the DTSTART to be this date because DTSTART is used to seed the rule...
[10:55:51] <Eliot> ok..
[10:55:52] <bdesruisseaux> Also... We have agreed to change the spec to specify that DTSTART SHOULD be synchronized with the RRULE...
[10:55:56] <cyrus_daboo> Bernard and I are on the same page, obviously...
[10:56:25] <Eliot> i saw one person push back. is that what others saw?
[10:56:50] <jonlennox> (Speaking of which, that doesn't work with BYSETPOS=-1...that should maybe be added to the issues list but probably not discussed right now.)
[10:57:23] <Eliot> i am still prepared to call this rough consensus
[10:57:26] <cyrus_daboo> However, I do understand the point that for "lazy" (that's not meant in a derogatory way) implementations being able to key of DTSTART as the first instance to exclude events from time-range queries is handy.
[10:57:48] <jonlennox> It's a useful optimization
[10:58:03] <bdesruisseaux> Well...
[10:58:18] <Eliot> guys... does anyone object to my position/
[10:58:19] <Eliot> ?
[10:58:21] <bdesruisseaux> For optmization please model your info in a database...
[10:58:28] <jonlennox> True.
[10:58:42] <cyrus_daboo> But you have to expand recurrences for time-range queries that do overlay,m so changes are you have a sorted list of earliest->latest instances anyway, so just use the earliest from that (which may be the DTSTART or an RDATE).
[10:58:59] <Eliot> hello?
[10:59:06] <jonlennox> Eliot: what was your position?
[10:59:06] <cyrus_daboo> Sorry my text was garbled.
[10:59:21] <Eliot> i am prepared to claim that we have rough consensus to allow an RDATE < DTSTART
[10:59:32] <alexeymelnikov> Fine with me
[10:59:37] <bdesruisseaux> Fine with me.
[10:59:44] <jonlennox> I think so.
[10:59:47] <cyrus_daboo> What I mean is that a database backend will likely have its own set of instance start/end values that can be independent of DTSTART - i.e. use RDATE if it were earlier.
[11:00:00] <Eliot> cyrus, unless you're objecting, let's move along
[11:00:20] <cyrus_daboo> Ok - with the exception that in a VTIMEZONE RDATE>=DTSTART - another issue.
[11:00:56] <Eliot> i'll accept that as a "move along". 79?
[11:01:25] <Eliot> http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue79
[11:02:10] <cyrus_daboo> So the first part of #79 basically requires RDATE>=DTSTART - so we are special casing this on VTIMEZONE.
[11:02:46] <bdesruisseaux> Why do you say so?
[11:04:21] <Eliot> cyrus, still there?
[11:04:43] <bdesruisseaux> We need to clarify that if an observance specify an "RDATE" and/or "RRULE" property, then the DTSTART is also considered as an onset time of an observance.
[11:05:24] <cyrus_daboo> You state that DTSTART is the onset, so there can be no instances before that.
[11:05:34] <bdesruisseaux> Of course when you have an RRULE... this is obvious... there will be an observance that will be generate by the RRULE with the same date-time value as DTSTART
[11:05:58] <bdesruisseaux> Cyrus: No! DTSTART is one onset...
[11:06:17] <bdesruisseaux> A DAYLIGHT or STANDARD sub-component can specify multiple onset times...
[11:06:49] <cyrus_daboo> Then we need to re-iterate here that DTSTART represents "one onset" and not the "first onset".
[11:07:22] <cyrus_daboo> Well, not necessarily the "first onset" as there may be RDATEs representing other onsets that occur earlier.
[11:07:46] <Eliot> it seems that reinhold agrees with you
[11:08:09] <Eliot> on that latter point. i think we need some text to argue over. am i wrong?
[11:09:30] <Eliot> ok - barring objection, bernard can you propose appropriate text?
[11:09:35] <bdesruisseaux> This specific issue of whether RDATE may be less than DTSTART was not mentionned in issue 79
[11:09:49] <bdesruisseaux> Issue 79 has two parts:
[11:10:13] <bdesruisseaux> 1- Is DTSTART always specify a onset date-time of an observance
[11:11:00] <bdesruisseaux> 2- Why is there a restrictino that if a DAYLIGHT or STANDARD only specify a DTSTART (i.e., no RDATE and no RRULE) then it must be the only sub-component in the VTIMEZONE ???
[11:11:46] <Eliot> so looking at 1, there seems to be some confusion on your use of "onset".
[11:12:30] <bdesruisseaux> My use of "onset" is inline with RFC2445!
[11:13:11] <bdesruisseaux> The date-time at which a specific time zone observance start to be in effect...
[11:14:04] <Eliot> so looking at the rfc 2445 example that reinhold quoted, the onset was in the RDATE, not in DTSTART, right?
[11:15:02] <Eliot> or at least that was his confusion.
[11:15:33] <Eliot> and perhaps mine, now?
[11:16:03] <bdesruisseaux> Reinhold made reference to an example that contained a big mistake...
[11:16:47] <Eliot> ok. so, in that example DTSTART should have been the earlier date?
[11:16:49] <bdesruisseaux> The DTSTART specified in the DAYLIGHT sub-component is actually a copy'n'paste of the DTSTART specified in the STANDARD sub-component.
[11:16:58] <Eliot> ok,
[11:18:03] <Eliot> so the person who would argue at all over this isn't here today. let me ping reinhold and see where he is on this issue.
[11:18:12] <Eliot> does anyone else object to bernard's proposed changes?
[11:18:26] <cyrus_daboo> No objection.
[11:19:08] <Eliot> ok. action is mine to ping reinhold. barring serious screaming on his part we have rough consensus.
[11:19:27] <bdesruisseaux> What about the 2nd part ?
[11:19:38] <bdesruisseaux> Are we okay to remove the restrictino?
[11:19:51] <Eliot> is there objection?
[11:20:45] <Eliot> no objections heard. barring objection on the mailing list, i'd move forward.
[11:20:50] <Eliot> next
[11:21:03] <bdesruisseaux> Issue 8 ?
[11:21:19] <bdesruisseaux> DURATION:P1D8H
[11:21:31] <Eliot> right -the mailing list clearly spoke on this point.
[11:22:01] <bdesruisseaux> Do we go with the proposal to compute the nominal duration first?
[11:22:09] <Eliot> and as i recall they said that we shouldn't disallow P1D8H
[11:22:19] <Eliot> but we do need an example of what happens
[11:23:22] <Eliot> are there objections to that course?
[11:23:29] <jonlennox> There's also the issue of what happens if the P1D hits a non-existent time.
[11:23:32] <cyrus_daboo> No - the text on the list I thought was pretty clear.
[11:23:36] <jonlennox> This interacts with issue 70.
[11:24:19] <Eliot> perhaps but in our discussions i thought we agreed that the ISO standard covers this ground sufficiently.
[11:24:38] <Eliot> ok, i'm not hearing objections.
[11:24:45] <jonlennox> I don't think the definition of nominal durations defined that case
[11:25:00] <Eliot> wasn't that what bernard quoted last week?
[11:25:31] <jonlennox> Not for the case where you start at 2:30 am this Saturday in America/New_York.
[11:25:36] <Eliot> otherwise, precisely which case isn't covered?
[11:26:17] <Eliot> that's not this issue, as i understand it.
[11:26:34] <Eliot> this issue is about duration, not start time.
[11:26:44] <jonlennox> The start time is well-defined.
[11:26:56] <jonlennox> DST is 2 - 3 am *Sunday*, P1D later.
[11:27:12] <jonlennox> That's Issue 70.
[11:27:33] <Eliot> ok, i see what you're saying
[11:28:05] <jonlennox> I think allowing P1D8H would make any resolution of issue 70 more complicated.
[11:28:21] <jonlennox> But maybe we should defer that until we actually take up issue 70.
[11:29:06] <Eliot> bernard, does the standard address this particular case?
[11:29:20] <Eliot> (8601)
[11:29:34] <bdesruisseaux> I don't know for sure.
[11:29:44] <bdesruisseaux> I haven't review 8601 since our last sessino
[11:30:18] <Eliot> ok, that's homework. guys we're done for today.
[11:30:34] <Eliot> have a good one.
[11:30:43] --- Eliot has left
[11:30:44] <bdesruisseaux> Thanks
[11:30:46] <bdesruisseaux> Bye
[11:30:47] <jonlennox> Do we have another Jabber before Prague?
[11:31:21] <cyrus_daboo> Bye.
[11:31:45] <bdesruisseaux> Jon: I don't know. I don't have it in my calendar..
[11:32:07] <jonlennox> If we don't, it resolves the "who eats the hour" problem. :-)
[11:32:09] <alexeymelnikov> I will be travelling to Prague, so I am likely to miss it
[11:32:20] --- alexeymelnikov has left
[11:32:28] <cyrus_daboo> As I posted to the list - we have a one hour change between N. America and Europe that we would have to argue over.
[11:32:35] <jonlennox> Right.
[11:32:42] <jonlennox> When does Europe change?
[11:32:55] <cyrus_daboo> Since we spent so much time arguing over DST issue lately, perhaps we should not have a session to avoid this one!
[11:34:20] <cyrus_daboo> Most European timezones switch on the last Sunday of March.
[11:34:53] <cyrus_daboo> Previous N.America was one week later, now it is two weeks before.
[11:35:50] <jonlennox> So Europe is switching the Sunday after the IETF, so if we don't have a Jabber 03-15, we're fine?
[11:36:22] <cyrus_daboo> Yes. That is the chairs call.
[11:36:37] <jonlennox> Pity I didn't catch Eliot.
[11:36:41] <jonlennox> Oh well.
[11:37:25] <jonlennox> Bye!
[11:37:27] --- jonlennox has left
[11:37:31] <cyrus_daboo> Bye
[11:37:33] --- cyrus_daboo has left
[16:43:13] --- bdesruisseaux has left: Logged out