Date parsing does not support whitespace

[ssenesi]

I got an error with r1028 when writing

start_date="1950-01-01 00:00:00 + 3d + 3d "

instead of

start_date="1950-01-01 00:00:00 +3d+3d"

[rlacroix]

I think there is indeed a bug but not the one you think you are reporting.

You are not supposed to be able to use two + signs there. The format should be date + duration (whitespaces are ignored). I'm not exactly sure how 1950-01-01 00:00:00 +3d+3d is parsed, my guess is that it is just like if you had written 1950-01-01 00:00:00 +3d.

I will ask Yann about this but I think the parsing should be improved to throw an error in both cases. I don't think we want to really support arithmetic operators there.

[ymipsl]

Yes, I agree. The "+" is not an arithmetic operator, just a way to define a date without using a specific calendar, i.e. for people that don't worry calendar. For example, you may want use only time and event defined is second.

[rlacroix]

In fact fixing the weird behavior with +3d+3d is sort of tricky. The first + is parsed as the separator between the date and the duration. Then 3d and +3d are both parsed as "3 days" since +3 is actually a valid number (i.e it's possible to write a date like +3d-5mi).

I guess the best way to fix this would be to disallow setting the same "unit" twice, i.e. make a duration like 3d 5d invalid.

[ssenesi]

That's up to you. I alleviated the issue for my use-case upstream XIos

[rlacroix]

Fixed in r1049.