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

Extend date parsing implementation #85

Open
sebsto opened this issue Dec 19, 2024 · 6 comments
Open

Extend date parsing implementation #85

sebsto opened this issue Dec 19, 2024 · 6 comments

Comments

@sebsto
Copy link
Contributor

sebsto commented Dec 19, 2024

As a follow up to #81

Given this is being used with more than HTTP headers I think we need to extend the number of timezone identifiers. The list is missing standard ones listed in RFC PST, EST, MST, CST (funnily RFC only lists US zones). Also does the parser deal with additional characters at the en. It is common to see email dates written as follows Sun, 22 Sep 2024 18:46:31 +0100 (BST) with the three character timezone at the end.

@sebsto
Copy link
Contributor Author

sebsto commented Dec 19, 2024

@t089 do you have time to give a look at this ?

@t089
Copy link
Contributor

t089 commented Dec 19, 2024

@adam-fowler do you have a link to a list of time zones that we should support?

@t089
Copy link
Contributor

t089 commented Dec 19, 2024

@adam-fowler
Copy link
Member

The same list is included in the later rfc's

@t089
Copy link
Contributor

t089 commented Dec 20, 2024

Not sure how much value it is to add those but not any other from the rest of the world. If we want to make truly general purpose date parser, we would need ICU data... Maybe for SES, we should not parse the Date header instead, and leave this exercise to the user?

@adam-fowler
Copy link
Member

Not sure how much value it is to add those but not any other from the rest of the world. If we want to make truly general purpose date parser, we would need ICU data... Maybe for SES, we should not parse the Date header instead, and leave this exercise to the user?

That certainly is an option.

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

3 participants