-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parse format "%Y%m%d" (no delimiter between fields) #25
Comments
Right ... %Y will happily continue to consume digits for the year, and there is no backtracking to retry failed matches with less greediness. If you know that your year spans exactly four digits, use the %E4Y specifier. That is "%E4Y%m%d" will successfully parse "20140304" as 2014-03-04. Aside: "%Y%m%d" on "20140304" doesn't return 1970-01-01 ... it fails (returns false) and leaves the output time_point alone. |
Great to know, thank you! I wonder whether this may possibly become a somewhat frequent issue when adopted as standard ("%Y" is quite common after all, as are time formats without delimiters), the format strings might better be kept backwards-compatible to strftime()/strptime(), and extensions should be pure extensions, without breaking traditional, expected behavior? A possible backwards-compatible format could be: "%Y" -- strptime()-like four-digit year YYYY What do you think? |
Hi, Thanks for the suggestion. We agree with you that this might be a not-totally-uncommon transition issue. However, we also think that the current greedy %Y is the "best" behavior. So, for the time being we'll add something more prominent to time_zone.h where %Y is described. However we will certainly raise this question during any standardization process. Thanks again. |
Hi,
cctz::parse() seems to fail for format strings without delimiters: "%Y-%m-%d" works fine, however "%Y%m%d" fails (for input strings like "2014-03-04" and "20140304", the latter returns 1970-01-01).
Is this a known issue?
Kind regards,
The text was updated successfully, but these errors were encountered: