who will laugh first

can you spot the error?

[lucy24]

If someone else were posting this question, the answer would jump right up and hit me in the face. But it's my own problem, so I'm overlooking something embarrassingly obvious.

expr = /((\[\d\d\/\w\w\w)\/20\d\d:(\d\d):\d\d:\d\d .+\n)\n([\d.]+ - - (\[\d\d\/\w\w\w)\/20\d\d:(\d\d))/m;

do
  {
  extra = "";
  flag = expr.test(output);
  if (flag != false)
    {
    day1 = expr.exec(output)[2];
    day2 = expr.exec(output)[5];
    hour1 = parseInt(expr.exec(output)[3]);
    hour2 = parseInt(expr.exec(output)[6]);

    if (day1 != day2)
      { extra = "\nDATE\n\n"; }
    if (hour1 < 6 && hour2 >= 6)
      { extra = "\n<tbody class = \"day\">\n"; }
    if (hour1 < 15 && hour2 >= 15)
      { extra = "<\/tbody>\n\n"; }
    output = output.replace(expr,"$1" + extra + "$4");
    }
  }
while (flag != false);

All of this works as intended. No false positives, no false negatives... EXCEPT that when hour1 = 9 and hour2 = 10, it thinks the second condition has been met and shoves in an extraneous <tbody...> line.

What, please, am I overlooking? :(

In case anyone wondered: The code was written for a specific situation, so the three conditions are de facto mutually exclusive. I run it locally and the text blocks aren't very big. So twiddling my thumbs while javascript does its stuff is definitely preferable to learning yet another language ;)

[Fotiman]

Can you post an example of output?

I suspect the problem is with the parseInt. You should always specify the radix value on parseInt, otherwise values that begin with "0" (like "09") will be treated as octal (base 8) instead of decimal (base 10). parseInt will give you 0 in this case (thus satisfying your hour1 < 6 condition).

Change your parseInt lines to:
hour1 = parseInt(expr.exec(output)[3], 10);
hour2 = parseInt(expr.exec(output)[6], 10);

Lesson: ALWAYS include the radix value on parseInt calls.

[lucy24]

Bingo. Didn't I say it would be something obvious that I know perfectly well? Default base 10 unless it's got a leading 0. I knew that. But the only other times I can remember using parseInt were either explicitly set to hexadecimal or they involved numbers that didn't use a leading zero.

To verify, I added a line that prints out the hour1 and hour2 values in addition to the intended output. Sure enough, times in "08" and "09" come through as 0. Ironically this means that the target range of 4-7 (that is, 5-6 allowing for gaps) is also being parsed as octal; it just happens to come out right because it's only one digit and it's less than 8. The "day" part isn't affected because that's just comparing strings. "08" != "09".

Aren't constructors fun? If your text editor is in RegEx mode, you have to start out with four \\\\ in order to end up with one \