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

strftime and strptime support #15

Closed
BurntSushi opened this issue Jul 10, 2024 · 1 comment
Closed

strftime and strptime support #15

BurntSushi opened this issue Jul 10, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@BurntSushi
Copy link
Owner

I thought I would have implemented these for the initial release, but I decided to cut scope so that I could get something out there.

I think it's questionable to be adding APIs like strptime. In particular, there's at least a few things to not like about it:

  • It is a IMO pretty inscrutable way to parse a datetime.
  • It interacts with localization in naive ways.

My retort to both of those concerns is:

  • While inscrutable, it is widely used. Folks seem to have a "the devil you know" relationship with it.
  • We can say up front that another crate should be used for localization purposes. But I don't think the lack of localization means we need to not do anything. There is still a wide use case for which "format datetimes as English in the Gregorian calendar" is useful.
@BurntSushi BurntSushi added the enhancement New feature or request label Jul 10, 2024
@BurntSushi
Copy link
Owner Author

RFC 2822 support done on Saturday, and strftime/strptime done on Sunday. Jiff doesn't support every conversion specifier known to exist, but I think we start with a good set. And because of tighter time zone integration, we don't suffer from this problem.

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

No branches or pull requests

1 participant