You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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:My retort to both of those concerns is:
The text was updated successfully, but these errors were encountered: