[fix #5044] Support converting 'yyyymmdd' format to date #5078
Conversation
arrow-cast/src/parse.rs
Outdated
| if string.len() != 6 && string.len() != 8 { | ||
| return None; | ||
| } | ||
| for ch in string.bytes() { | ||
| if ch < b'0' || ch > b'9' { | ||
| return None; | ||
| } | ||
| } | ||
| let (year, month, day) = match string.len() { | ||
| 6 => ( | ||
| parse_two_digit_year(digits[0] as i32 * 10 + digits[1] as i32) as u16, | ||
| digits[2] * 10 + digits[3], | ||
| digits[4] * 10 + digits[5], | ||
| ), | ||
| 8 => ( | ||
| digits[0] as u16 * 1000 | ||
| + digits[1] as u16 * 100 | ||
| + digits[2] as u16 * 10 | ||
| + digits[3] as u16, | ||
| digits[4] * 10 + digits[5], | ||
| digits[6] * 10 + digits[7], | ||
| ), | ||
| _ => return None, | ||
| }; |
There was a problem hiding this comment.
| if string.len() != 6 && string.len() != 8 { | |
| return None; | |
| } | |
| for ch in string.bytes() { | |
| if ch < b'0' || ch > b'9' { | |
| return None; | |
| } | |
| } | |
| let (year, month, day) = match string.len() { | |
| 6 => ( | |
| parse_two_digit_year(digits[0] as i32 * 10 + digits[1] as i32) as u16, | |
| digits[2] * 10 + digits[3], | |
| digits[4] * 10 + digits[5], | |
| ), | |
| 8 => ( | |
| digits[0] as u16 * 1000 | |
| + digits[1] as u16 * 100 | |
| + digits[2] as u16 * 10 | |
| + digits[3] as u16, | |
| digits[4] * 10 + digits[5], | |
| digits[6] * 10 + digits[7], | |
| ), | |
| _ => return None, | |
| }; | |
| let (year, month, day) = match (mask, string.len()) { | |
| (0b111111, 6) => ( | |
| parse_two_digit_year(digits[0] as i32 * 10 + digits[1] as i32) as u16, | |
| digits[2] * 10 + digits[3], | |
| digits[4] * 10 + digits[5], | |
| ), | |
| (0b11111111, 8) => ( | |
| digits[0] as u16 * 1000 | |
| + digits[1] as u16 * 100 | |
| + digits[2] as u16 * 10 | |
| + digits[3] as u16, | |
| digits[4] * 10 + digits[5], | |
| digits[6] * 10 + digits[7], | |
| ), | |
| _ => return None, | |
| }; |
arrow-cast/src/parse.rs
Outdated
| @@ -544,6 +544,18 @@ const EPOCH_DAYS_FROM_CE: i32 = 719_163; | |||
| /// Error message if nanosecond conversion request beyond supported interval | |||
| const ERR_NANOSECONDS_NOT_SUPPORTED: &str = "The dates that can be represented as nanoseconds have to be between 1677-09-21T00:12:44.0 and 2262-04-11T23:47:16.854775804"; | |||
|
|
|||
| fn parse_two_digit_year(input_year: i32) -> i32 { | |||
There was a problem hiding this comment.
Could we get a doc comment explaining what this is doing, and perhaps linking to the docs of the system it is based on?
There was a problem hiding this comment.
FWIW https://www.rfc-editor.org/rfc/rfc3339#section-3 explicitly disallows 2 digit years as they are ambiguous
There was a problem hiding this comment.
FWIW https://www.rfc-editor.org/rfc/rfc3339#section-3 explicitly disallows 2 digit years as they are ambiguous
It refer to https://www.postgresql.org/docs/current/datatype-datetime.html
There was a problem hiding this comment.
FWIW https://www.rfc-editor.org/rfc/rfc3339#section-3 explicitly disallows 2 digit years as they are ambiguous
Maybe you need to make a decision if two digit year should be supported, and I will finish this PR by the decision.
There was a problem hiding this comment.
I think we should not support them
There was a problem hiding this comment.
I think we should not support them
Okey. I will modify the code. Thanks for suggestion
|
Marking as draft to show this isn't waiting on a review, feel free to unmark when you would like me to take another look |
Tangruilin
force-pushed
the
fix#5044
branch
2 times, most recently
from
3571d58 to
1c4520a
Compare
Tangruilin
force-pushed
the
fix#5044
branch
2 times, most recently
from
b5317ef to
e032f02
Compare
Signed-off-by: tangruilin <[email protected]>
I modify the code as comment, now you can retry it |
Which issue does this PR close?
Closes #5044 .
Rationale for this change
format "yyyymmdd" and "yymmdd" cannot be converted to DateType, which do not comply with the ISO standard
What changes are included in this PR?
the way to parse "yyyymmdd" and "yymmdd" are added to parse_date
Are there any user-facing changes?
no