[09:57:34] --- eliot.lear has joined
[09:58:20] --- bdesruisseaux has joined
[09:58:39] <eliot.lear> howdy!
[09:58:41] <bdesruisseaux> Hi Eliot!
[09:59:03] <eliot.lear> so.. the issue tracker is cooked
[09:59:59] <eliot.lear> to make a long story short, i couldn't replace my existing system easily, and roundup required older software than i could install to get it all working
[10:00:06] <eliot.lear> so, i am attempting to fetch the data.
[10:00:19] <eliot.lear> the good news is that i think we covered nearly all issues
[10:00:26] <eliot.lear> as it was very late in the process
[10:01:28] <bdesruisseaux> You mean you had no back up! :-|
[10:01:55] <eliot.lear> i have a backup. i just can't use it
[10:02:08] <eliot.lear> the data is there. the application is toast.
[10:02:15] <eliot.lear> has to do with python version mismatches
[10:02:25] <eliot.lear> roundup 1.0 worked with python 2.4 and not 2.5.
[10:02:50] <bdesruisseaux> and you can't get python 2.4 anymore?
[10:02:51] <eliot.lear> and when i reassembled my new system, i needed to upgrade to support SATA, and i did it the fast and easy way
[10:03:21] <eliot.lear> by going to SuSE 10.2. the problem is that i don't know what in 10.2 depends on python 2.5, if anything
[10:04:37] <bdesruisseaux> I see.
[10:05:16] <bdesruisseaux> BTW, I have addressed the two issues that were brought up on the mailing list recently and didn't seem too controversial.
[10:05:22] <eliot.lear> ok
[10:05:31] <eliot.lear> well, it may be just the two of us...
[10:05:35] <bdesruisseaux> The one brought up by Jeffrey about the UNTIL rule part
[10:05:52] --- alexeymelnikov has joined
[10:06:01] <bdesruisseaux> and the one about the TZID on DATE values (it is not forbidden).
[10:06:13] <eliot.lear> ok
[10:06:13] <bdesruisseaux> (it is NOW forbidden) oops!
[10:06:37] <eliot.lear> the draft is coming through now
[10:06:44] <bdesruisseaux> good
[10:07:11] <eliot.lear> are you ready to submit?
[10:07:16] <bdesruisseaux> NO!
[10:07:53] <eliot.lear> so i see that you have 11, 61, 63, 65, 79, and two additional still "open"
[10:08:02] <bdesruisseaux> correct
[10:08:31] <bdesruisseaux> and there are some issues from Jon that aren't listed...
[10:08:37] <eliot.lear> from memory, 11 is just VTODO
[10:08:48] <bdesruisseaux> No, that was 10.
[10:08:57] <eliot.lear> ok...
[10:09:09] <eliot.lear> hang on a sec
[10:09:13] <bdesruisseaux> I address 10 for both VEVENT and VTODO yesterdays by mostly adding new examples.
[10:11:20] <bdesruisseaux> For issue 11 we said we should add the table from Cyrus... but nobody commented on Cyrus' table on the mailing list...
[10:12:02] --- cyrus_daboo has joined
[10:12:06] <eliot.lear> howdy cyrus
[10:12:12] <bdesruisseaux> hi cyrus!
[10:12:26] <cyrus_daboo> Hi - sorry busy fixing a server...
[10:12:44] <eliot.lear> ok, i have it
[10:12:44] <alexeymelnikov> Hi Cyrus
[10:13:09] <eliot.lear> you're right. nowbody commented on cyrus' table.
[10:13:32] <cyrus_daboo> Well put it in the draft and see if that makes someone comment!
[10:13:38] <eliot.lear> !!
[10:14:01] <eliot.lear> i think that's appropriate
[10:14:08] <cyrus_daboo> Actually there was a comment from the guy at rockliffe if I am not mistaken.
[10:14:26] <eliot.lear> Nigel
[10:15:10] <cyrus_daboo> Right - I think he was claiming that the table could be vastly simplified by eliminating the notes in some fashion. But I did not follow what he was talking about. Probably should re-read that.
[10:15:11] <eliot.lear> cyrus what did you think of his changes?
[10:15:26] <eliot.lear> he actually had several clarifications
[10:15:54] <eliot.lear> He was particularly a fan of "These are only valid for MONTHLY+ or YEARLY rules."
[10:16:48] <eliot.lear> does everyone have the message?
[10:17:33] <eliot.lear> hello?
[10:17:52] <bdesruisseaux> I believe a BYDAY rule part that specifies a numeric value (e.g., "2SU") only makes sense with FREQ=YEARLY or FREQ=MONTHLY
[10:18:21] <bdesruisseaux> Eliot: Yes I have the message from Nigel.
[10:18:26] <eliot.lear> ok
[10:18:57] <eliot.lear> right
[10:19:17] <eliot.lear> and i think that was his point
[10:19:48] <bdesruisseaux> I would actually specify a "MUST NOT"
[10:19:56] <eliot.lear> ok
[10:20:14] <cyrus_daboo> Ok - som some of he comments related to the fact that the "Notes" portion of the table encoded behaviors that he thought were not specified in the spec and thus text needed to be added.
[10:20:33] <eliot.lear> right.
[10:20:54] <eliot.lear> particularly note 3
[10:21:00] <eliot.lear> and note 2 as well
[10:21:35] <eliot.lear> but he had corrective text. with bernard's caveat, is his text acceptable?
[10:22:12] <cyrus_daboo> No. His changes would make most VTIMEZONEs illegal, I think.
[10:23:13] <eliot.lear> (reading again)
[10:23:19] <cyrus_daboo> e.g. he says that the BYDAY with numeric value should always be an offset in the year. Yet VTIMEZONEs use FREQ=YEARLY;BYMONTH=3;BYDAY-3SU - and that means the third last Sunday in March, not the third last Sunday in the year.
[10:23:55] <bdesruisseaux> The text change proposed for BYDAY is okay, but Cyrus is right that his next comment on "Note 3" would make pretty much all VTIMEZONE invalid...
[10:24:25] <eliot.lear> ok, let's break this up
[10:24:34] <eliot.lear> are his changes to note 1 acceptable??
[10:25:44] <cyrus_daboo> Note 1 change looks OK to me.
[10:25:52] <eliot.lear> bernard?
[10:27:05] <eliot.lear> what about Note 2 changes?
[10:27:07] <bdesruisseaux> hold
[10:27:23] <bdesruisseaux> checking which note is which!
[10:29:02] <bdesruisseaux> Okay, Note 1 should be changed to say that BYDAY MUST NOT specify a numeric value if FREQ is not YEARLY nor MONTHLY. Right?
[10:29:09] <eliot.lear> right
[10:29:25] <cyrus_daboo> Actually no to note 1. He claims that a numeric value should only be used for YEARLY/MONTHLY. My claim is that it cannot be used with WEEKLY, but OK for the rest.
[10:29:58] <cyrus_daboo> What is wrong with FREQ=DAILY;BYDAY=2SU?
[10:30:24] <bdesruisseaux> well... you would need to specify that its the 2nd Sunday of something.... of the year? of the month?
[10:30:34] <cyrus_daboo> Right!
[10:30:53] <bdesruisseaux> Either we specify a default... or we forbid it...
[10:30:57] <bdesruisseaux> I would forbid it!
[10:31:02] <cyrus_daboo> But perhaps that means the second Sunday in the set starting with the DTSTART on the event!
[10:31:13] <cyrus_daboo> Kind of silly, though.
[10:31:35] <bdesruisseaux> It could mean whatever we want! But at the end of the day it wouldn't be useful!
[10:31:43] <cyrus_daboo> But what about FREQ=DAILY;BYMONTH=2;BYDAY=2SU?
[10:31:45] <bdesruisseaux> Let's forbid it to simply everybody's life
[10:31:51] <cyrus_daboo> That is anchored to the second month.
[10:32:22] <eliot.lear> cyrus, what does that expression mean? how does DAILY mean anything there?
[10:32:35] <bdesruisseaux> :-)
[10:32:57] <bdesruisseaux> Everyday in February... but really only the 2nd second! Whoohoo
[10:33:08] <bdesruisseaux> the 2nd Sunday (oops)
[10:33:14] <cyrus_daboo> DAILY defines the initial set of dates, BYMONTH restrticts that to February and then BYDAY the second Sunday.
[10:33:19] <eliot.lear> this seems to be a case of "dr. my head hurts"
[10:33:55] <cyrus_daboo> This is the same as FREQ=MONTHLY;BYMONTH=2;BYDAY=2SU or FREQ=YEARLY;BYMONTH=2;BYDAY=2SU
[10:34:15] <eliot.lear> precisely so. who would write such a thing?
[10:34:17] <cyrus_daboo> There are many different ways to do the same thing with RRULE. That is what makes it a pain at times.
[10:34:38] <eliot.lear> ok, so how do we dispose of this proposed change?
[10:34:51] <bdesruisseaux> In practice though all clients will do: FREQ=YEARLY;BYMONTH=2;BYDAY=2SU
[10:35:06] <cyrus_daboo> Its allowed by the spec right now. We can outlaw it given that there are other ways to achieve the same thing.
[10:35:08] <eliot.lear> yes.
[10:35:19] <eliot.lear> bernard?
[10:35:45] <bdesruisseaux> Please clarify the proposal
[10:35:57] <bdesruisseaux> Go with the MUST NOT I previously proposed?
[10:36:38] <cyrus_daboo> Yes, but lets try to avoid too many negatives. How about:
[10:36:39] <eliot.lear> i think that's what we're saying, right Cyrus? or are we saying that we shouldn't write "don't bang your head against the wall " writing contorted RRULEs
[10:36:39] <eliot.lear> ?
[10:36:53] <cyrus_daboo> MUST NOT specify a numeric value unless the FREQ is YEARLY or MONTHLY.
[10:37:01] <eliot.lear> ok
[10:37:04] <eliot.lear> next
[10:37:07] <eliot.lear> note 2
[10:37:40] <eliot.lear> this seems uncontroversial
[10:37:44] <eliot.lear> (so he says)
[10:38:41] <bdesruisseaux> Should we add rows in the table to separate BYDAY with and without a numeric value?
[10:38:55] <cyrus_daboo> OK - so Note 2 would need to be adjusted to remove the BYYEARDAY comment since that cannot occur. Then the text needs to reflect that.
[10:40:01] <cyrus_daboo> I have changed my source copy of the table to reflect that.
[10:40:13] <eliot.lear> cyrus, can you provide that back to bernard?
[10:40:26] <bdesruisseaux> In my opinion the text in the notes really should be merged in the text where it really belongs
[10:40:35] <cyrus_daboo> Will do once we have all the correction done.
[10:40:50] <eliot.lear> bernard, i think that's a good idea.
[10:40:59] <eliot.lear> if you can find a right place.
[10:41:08] <bdesruisseaux> We should also clarify what N/A means in the table....
[10:41:18] <bdesruisseaux> is it a combination that is forbidden?
[10:41:22] <cyrus_daboo> I agree that all the restrictions in the table need to be in the text. I think that is what Nigel was trying to do.
[10:41:27] <bdesruisseaux> i.e., you MUST NOT do that
[10:41:45] <cyrus_daboo> I will add a definition of N/A in the "note table.
[10:42:04] <eliot.lear> thanks
[10:42:33] <eliot.lear> so he's misunderstood note 2 is what we're saying?
[10:42:57] <eliot.lear> or more appropriately he's misunderstood BYYEARDAY?
[10:43:05] <eliot.lear> he's saying that there are no restrictions currently
[10:43:20] <eliot.lear> (at least not elsewhere in the spec)
[10:43:34] <cyrus_daboo> There is no restriction in the text. But there ought to be.
[10:43:40] <eliot.lear> ok
[10:43:46] <eliot.lear> Bernard?
[10:43:54] <bdesruisseaux> hold on
[10:46:04] <bdesruisseaux> I'm not sure I understand note 2 either...
[10:46:22] <bdesruisseaux> Why saying that BYDAY is Limiting when used with BYYEARDAY?
[10:46:33] <bdesruisseaux> Isn't it BYYEARDAY that is Limiting in the end?
[10:47:16] <eliot.lear> that's what i would think
[10:47:36] <cyrus_daboo> His point is that in the table, BYYEARDAY is only ever allowed with FREQ=YEARLY. The Note 2 comment is about FREQ=MONTHLY, so BYYEARDAY has no relevance there.
[10:47:37] <eliot.lear> and i think, cyrus, you meant "offset within the month"
[10:48:01] <eliot.lear> so we should say the former
[10:48:14] <cyrus_daboo> Yes - 'with the month' -> 'within the month'. I noticed several instances of that and I will fix.
[10:49:29] <bdesruisseaux> Ok, so we remove BYYEARDAY from Note 2. And add the restriction proposed by Nigel.
[10:49:40] <eliot.lear> cyrus?
[10:50:34] <cyrus_daboo> I would still argue that there is no need for BYYEARDAY with anything other than YEARLY. He says SECONDLY/MINUTELY/HOURLY/DAILY/WEEKLY should be allowed. I say lets make it simple and not do those.
[10:51:14] <eliot.lear> certainly daily/weekly i agree with
[10:51:34] <eliot.lear> secondly, minutely, and hourly you do actually lose something, but it's not alot
[10:51:38] <bdesruisseaux> Cyrus what's the issue?
[10:51:52] <bdesruisseaux> Every hour on the 44th day of the year...
[10:53:04] <eliot.lear> the question is if anyone will ever use this, and if it really saves anyone anything to remove it
[10:53:24] <cyrus_daboo> Ok, so maybe SECONDLY/MINUTELY/HOURLY, but DAILY/WEEKLY deinitiely not.
[10:53:29] <eliot.lear> right
[10:53:32] <bdesruisseaux> yes
[10:53:42] <eliot.lear> done
[10:53:48] <eliot.lear> and we're saying no to note three?
[10:53:54] <cyrus_daboo> OK, I can adjust the table accordingly and Bernard can use Nigel's text.
[10:55:17] <bdesruisseaux> Please send the updated table to the mailing list
[10:55:31] <cyrus_daboo> Will doo once we've got through all the other points
[10:55:42] <bdesruisseaux> Note 3 is big!
[10:56:01] <cyrus_daboo> Can we skip Note 3 for now, and continue with his other comments?
[10:56:14] <eliot.lear> i think we just covered the first portion of your note 3, no?
[10:56:36] <cyrus_daboo> No we were on note 2.
[10:56:51] <eliot.lear> no, but look at Note 3 first sentence
[10:56:55] <bdesruisseaux> Ok. Nigel's simple comment on note 3 was wrong.
[10:57:51] <eliot.lear> ok, bernard, can you expand on his wrongness?
[10:57:56] <eliot.lear> preferrably to him?
[10:58:17] <cyrus_daboo> Right. I also see that Note 3 in fact applies to more than the one table cell it appears in, as it references other FREQ values.
[10:58:18] <bdesruisseaux> I'm talking of: - In Note 3 it says the numeric value might be an offset into the month or the year. I think this is an unhelpful, unintuative special case that contradicts the spec, and would rather the numeric value in a YEARLY rule is always the offset within the year.
[10:58:39] <bdesruisseaux> If we go with what he is saying, most VTIMEZONE would become invalid
[10:58:43] <eliot.lear> right
[10:59:12] <eliot.lear> so don't accept.
[11:00:02] <eliot.lear> fair enough?
[11:00:13] <cyrus_daboo> Fair enough.
[11:00:22] <eliot.lear> are we done with 11?
[11:00:29] <bdesruisseaux> No!
[11:00:47] <bdesruisseaux> In the text right now we say something like
[11:01:05] <bdesruisseaux> "this rule part is only valid for YEARLY rules"
[11:01:18] <cyrus_daboo> BYWEEKNO you mean?
[11:01:32] <cyrus_daboo> Which comment of Nigel's are you referring to?
[11:01:35] <bdesruisseaux> Should that be reprhased with a MUST NOT statement instead?
[11:01:49] <bdesruisseaux> (I'm not talking of any specific case here...)
[11:02:02] <bdesruisseaux> just about the way restrictions should be written
[11:02:04] <cyrus_daboo> Yes - I think we should use MUST/MUST NOT rather than valid/not valid.
[11:02:11] <eliot.lear> yes
[11:02:39] <eliot.lear> this is both for BYWEEKNO and BYYEARDAY?
[11:02:54] <bdesruisseaux> Back to BYDAY with BYMONTHDAY
[11:03:04] <bdesruisseaux> Why do we say that BYDAY is limiting?
[11:03:24] <bdesruisseaux> Isn't it BYMONTHDAY that is limiting?
[11:03:59] <cyrus_daboo> Not for MONTHLY/YEARLY which is what the note refers to.
[11:04:38] <bdesruisseaux> Let's look at Nigel's example: FREQ=MONTHLY;BYDAY=MO;BYMONTHDAY=1,2,3,4,5,6,7,8,9,10,11,12,13,14
[11:05:14] <cyrus_daboo> That returns every MO in the first two weeks of every month.
[11:05:36] <eliot.lear> but who would write that?
[11:05:36] <cyrus_daboo> Remember, BYDAY is evaluated AFTER BYMONTHDAY
[11:05:55] <bdesruisseaux> oh... that's what I was missing
[11:07:00] <eliot.lear> i'm sorry - where did that leave us?
[11:07:31] <bdesruisseaux> Now I think the remaining of Note 2 is okay!
[11:07:50] <eliot.lear> next?
[11:08:18] <cyrus_daboo> Actually Eliot: FREQ=MONTHLY;;BYMONTHDAY=13,14,15;BYDAY=-1MO,-1TU,-1WE,-1TH,-1FR is useful. That is: the fifteenth on the month or the preceeding Friday, if the 15th is a Saturday or Sunday. ie. a "weekend shoft".
[11:08:52] <eliot.lear> ok
[11:09:05] <eliot.lear> so bernard, you've gotten me lost. where are we in nigel's note?
[11:09:17] <bdesruisseaux> note sure either
[11:09:20] <cyrus_daboo> I think we are at the first comment after note 2
[11:09:40] <cyrus_daboo> Starts with "The table implies WEEKLY + BYMONTHDAY is not allowed"
[11:09:48] <eliot.lear> right
[11:10:08] <cyrus_daboo> I think is suggestion is Ok for that one.
[11:10:19] <eliot.lear> bernard?
[11:11:04] <bdesruisseaux> ok
[11:11:09] <eliot.lear> next
[11:12:04] <cyrus_daboo> He suggests correcting the table or changing the spec. Since the spec states what was there before, I actually propose we fix the table.
[11:12:22] <eliot.lear> bernard?
[11:14:00] <bdesruisseaux> You want to allow WEEKLY + BYMONTHDAY? Why?
[11:14:02] <cyrus_daboo> Actually it is possible that is another case where SECONDLY/MINUTELY/HOURLY/YEARLY is allowed but not the others. i.e. the same as BYYEARDAY
[11:14:45] <cyrus_daboo> Actually, DAILY would be OK too: every day in the 22 week.
[11:15:03] <eliot.lear> we shouldn't allow WEEKLY+BYMONTHDAY
[11:15:24] <cyrus_daboo> So I guess I have changed my position. The table is correct and the spec should be changed!
[11:16:31] <eliot.lear> bernard?
[11:16:32] <bdesruisseaux> WEEKLY + BYMONTHDAY would be equivalent to MONTHLY + BYMONTHDAY... right?
[11:16:40] <eliot.lear> sure
[11:16:50] <eliot.lear> wait
[11:16:52] <cyrus_daboo> Yes - its redundant.
[11:16:52] <eliot.lear> no
[11:17:29] <eliot.lear> MONTHLY+BYMONTHDAY seems fine, is it not?
[11:17:38] <cyrus_daboo> Yes.
[11:17:42] <bdesruisseaux> Yes
[11:17:47] <eliot.lear> whereas WEEKLY +BYMONTHDAY is broken
[11:18:01] <bdesruisseaux> It's not broken... it would give you the same as with MONTLY
[11:18:31] <eliot.lear> So.. FREQ=WEEKLY;BYMONTHDAY=15 means what?
[11:18:32] <bdesruisseaux> Mind you I'm not considering BYSETPOS here!
[11:18:49] <cyrus_daboo> Actually not: if its only BYMONTHDAY then we have the problem as before: which month is it referring to. If it were BYMONTH=2;BYMONTHDAY=xx then it would be OK.
[11:19:05] <cyrus_daboo> But that is the same as MONTHLY;BYMONTH;BYMONTHDAY
[11:19:13] <eliot.lear> oops -sorry. misread
[11:19:38] <eliot.lear> i'm okay with MONTHLY;BYMONTHDAY.
[11:19:42] <bdesruisseaux> I'm not following you Cyrus
[11:19:59] <eliot.lear> guys - i have to stop now.
[11:20:00] <bdesruisseaux> There is no issue finding which month...
[11:20:10] <cyrus_daboo> OK - well ignore my comments. The question is whether WEEKLY + BYMONTHDAY is useful,
[11:20:16] <eliot.lear> right
[11:20:18] <bdesruisseaux> :-)
[11:20:21] <bdesruisseaux> I don't think it is!
[11:20:28] <eliot.lear> bernard, agree
[11:20:42] <eliot.lear> ok, feel free to continue but i need to take off (baby waiting)
[11:21:06] <eliot.lear> bernard, i need you to take your best shot at the open issues.
[11:21:20] <bdesruisseaux> I will do my best!
[11:21:21] <cyrus_daboo> Then the table is correct as-is but the text is wrong as the text only allows YEARLY+BYMONTHDAY
[11:21:32] <eliot.lear> ok. thanks all (please continue if you like)
[11:21:36] --- eliot.lear has left
[11:21:37] <bdesruisseaux> I'm not 100% this will be the draft for the WGLC but it will be close...
[11:21:42] <cyrus_daboo> OOps - note we were actually talking about BYWEEKNO, but the same applies to BYMONTHDAY too.
[11:21:44] <bdesruisseaux> I have to go too
[11:21:59] <bdesruisseaux> cheers
[11:22:01] --- bdesruisseaux has left
[11:22:12] <cyrus_daboo> bye
[11:22:15] --- cyrus_daboo has left
[12:12:28] --- alexeymelnikov has left
[14:23:30] --- alexeymelnikov has joined
[15:38:21] --- alexeymelnikov has left
[21:49:12] --- bdesruisseaux has joined
[21:49:36] --- bdesruisseaux has left