Possible bug in DvDate?

Reference Implementation: Java (archive)
1

Hi, Maybe it is a bug, maybe it is my misunderstanding, please help me out.

Thanks in advance

Bert

2

Maybe the linenumbers in the Exception are not completely correct,
because I changed the code layout for readability.

Bert

3

Bert Verhees schreef:

Maybe the linenumbers in the Exception are not completely correct,
because I changed the code layout for readability.

Let me explain what I found out.

The DvDate constructor for two integers constructs a value-string with a
single digit for a month below oktober

        super(DvDateTimeParser.convertDate(year, month, 1));
        setValue(year + "-" + month);
        setBooleans(true, true, false);
    }

Then when this value is used to construct a DvDate it is parsed against
the BDATE pattern-string in DvDateTimeParser
This looks like this:
BDATE = "(\\d){4}((\\d){2}((\\d){2})?)?";

My question is: what should change, the parser string or the
two-integer-constructor from DvDate. I am really not good in reading
regular expressions.

So I start the easy way, reading the ISO 8601, especially, the short
version: http://www.w3.org/TR/NOTE-datetime
It sais that the month-number should always be two digits.

This means, there is an error in the DvDate two-integer constructor.

If I am wrong, please let me know
Bert

4

Bert Verhees schreef:

Maybe the linenumbers in the Exception are not completely correct,
because I changed the code layout for readability.

Let me explain what I found out.

The DvDate constructor for two integers constructs a value-string with a
single digit for a month below oktober

super(DvDateTimeParser.convertDate(year, month, 1));
setValue(year + “-” + month);
setBooleans(true, true, false);
}

Then when this value is used to construct a DvDate it is parsed against
the BDATE pattern-string in DvDateTimeParser
This looks like this:
BDATE = “(\d){4}((\d){2}((\d){2})?)?”;

My question is: what should change, the parser string or the
two-integer-constructor from DvDate. I am really not good in reading
regular expressions.

So I start the easy way, reading the ISO 8601, especially, the short
version: http://www.w3.org/TR/NOTE-datetime
It sais that the month-number should always be two digits.

This means, there is an error in the DvDate two-integer constructor.

Hi Bert,

The pattern used by the parser is correct since it indicates the month number to be 2 digits. So the constructor that takes string parameter does the correct validation and rejects the parameter ‘1999-9’, which has only 1 digit for month.

What could be improved is the constructor that takes two integer and generates the string value by concating like this: year + “-” + month, which is not sufficient if the month has only one digit.

Will you take the honor to fix this with a supplementary unit testcase? =)

Cheers,
Rong

5

Rong Chen schreef:

    Bert Verhees schreef:
    > Maybe the linenumbers in the Exception are not completely correct,
    > because I changed the code layout for readability.
    Let me explain what I found out.

    The DvDate constructor for two integers constructs a value-string
    with a
    single digit for a month below oktober

           super(DvDateTimeParser.convertDate(year, month, 1));
           setValue(year + "-" + month);
           setBooleans(true, true, false);
       }

    Then when this value is used to construct a DvDate it is parsed
    against
    the BDATE pattern-string in DvDateTimeParser
    This looks like this:
    BDATE = "(\\d){4}((\\d){2}((\\d){2})?)?";

    My question is: what should change, the parser string or the
    two-integer-constructor from DvDate. I am really not good in reading
    regular expressions.

    So I start the easy way, reading the ISO 8601, especially, the short
    version: http://www.w3.org/TR/NOTE-datetime
    It sais that the month-number should always be two digits.

    This means, there is an error in the DvDate two-integer constructor.

Hi Bert,

The pattern used by the parser is correct since it indicates the month
number to be 2 digits. So the constructor that takes string parameter
does the correct validation and rejects the parameter '1999-9', which
has only 1 digit for month.

What could be improved is the constructor that takes two integer and
generates the string value by concating like this: year + "-" + month,
which is not sufficient if the month has only one digit.

OK, it just generates a wrong "value", not according ISO 8601 if the
month is below 10, it also does wrong if the day is below 10 (on three
digit constructor).

Just wanted to mention that, but did it in a polite way.

Bert

6

Hi Bert,

You are right. There are problems in these constructors that take integer values. The issues only exist in DvDate, but not in DvTime and DvDateTime where the string values are generated based on patterns rather than rudimentary string concatenation. Now they are fixed on the trunk.

Thanks for the reporting the issues!

Cheers,
Rong

7

Rong Chen schreef:

Hi Bert,

You are right. There are problems in these constructors that take
integer values. The issues only exist in DvDate, but not in DvTime and
DvDateTime where the string values are generated based on patterns
rather than rudimentary string concatenation. Now they are fixed on
the trunk.

Thanks for the reporting the issues!

Thanks for the fix, I take a look later
Bert