| 2010-09-10 12:00:12 |
Curtis Hovey |
description |
The expiration date field only accepts dates in the form of YYYY-MM-DD. Variations such as YYYY-M-D (or -MM-D or -M-DD) leads to unexpected results.
When changing someone's expiration date:
2011-4-1 will set it to January 1st, 2011.
2011-09-7 will set it to September 1st, 2011.
(Currently, these will show up as Dec 31, 2010 and August 31, 2011 due to bug #444760.)
It appears to validate dates against a strict YYYY-MM-DD parser, and ignores anything after the first piece of data it sees that doesn't fit that mold.
There is no warning or text mentioning that the date must be in that form, and no warning that information is being thrown away in the processing. |
The team membership expiration date field only accepts dates in the form of YYYY-MM-DD. Variations such as YYYY-M-D (or -MM-D or -M-DD) leads to unexpected results.
When changing someone's expiration date:
2011-4-1 will set it to January 1st, 2011.
2011-09-7 will set it to September 1st, 2011.
(Currently, these will show up as Dec 31, 2010 and August 31, 2011 due to bug #444760.)
It appears to validate dates against a strict YYYY-MM-DD parser, and ignores anything after the first piece of data it sees that doesn't fit that mold.
There is no warning or text mentioning that the date must be in that form, and no warning that information is being thrown away in the processing.
|
|
