Opened 5 years ago

Closed 5 years ago

#115 closed defect (fixed)

Date parsing does not support whitespace

Reported by: ssenesi Owned by: rlacroix
Priority: minor Component: XIOS
Version: 2.0 Keywords:
Cc:

Description

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"

Change History (6)

comment:1 Changed 5 years ago by ymipsl

  • Owner changed from ymipsl to rlacroix

comment:2 Changed 5 years ago by 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.

comment:3 Changed 5 years ago by 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.

comment:4 Changed 5 years ago by 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.

comment:5 Changed 5 years ago by ssenesi

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

comment:6 Changed 5 years ago by rlacroix

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in r1049.

Note: See TracTickets for help on using tickets.