Skip to content
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

Closed
Siesh1oo opened this issue May 13, 2016 · 3 comments
Closed

Parse format "%Y%m%d" (no delimiter between fields) #25

Siesh1oo opened this issue May 13, 2016 · 3 comments

Comments

@Siesh1oo
Copy link

Siesh1oo commented May 13, 2016

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,

@devbww
Copy link
Contributor

devbww commented May 13, 2016

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.

@devbww devbww closed this as completed May 13, 2016
@Siesh1oo
Copy link
Author

Siesh1oo commented May 13, 2016

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
"%E#Y" -- Year with # digits of fractional precision
"%EY" -- Year with arbitrary fractional precision

What do you think?

@devbww
Copy link
Contributor

devbww commented May 17, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants