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

Support "YYYY-MM-DD HH:MM:SS.mmmmmm" format #20

Open
Code-Hex opened this issue Sep 4, 2023 · 1 comment
Open

Support "YYYY-MM-DD HH:MM:SS.mmmmmm" format #20

Code-Hex opened this issue Sep 4, 2023 · 1 comment

Comments

@Code-Hex
Copy link

Code-Hex commented Sep 4, 2023

Thanks for making the great library!

Do you have plans to support a parser that allows spaces instead of the 'T' character in the format YYYY-MM-DD HH:MM:SS.mmmmmm?

Quoting an earlier version of the ISO 8601 standard, section 4.3.2:

The character [T] shall be used as time designator to indicate the start of the representation of the time of day component in these expressions. [...]

NOTE By mutual agreement of the partners in information interchange, the character [T] may be omitted in applications where there is no risk of confusing a date and time of day representation with others defined in this International Standard.

https://stackoverflow.com/questions/9531524/in-an-iso-8601-date-is-the-t-character-mandatory

@relvacode
Copy link
Owner

Hi there,

The goal of this library was always for interop with other languages/interfaces that don't follow RFC3339 in a way the stdlib time understands.

The StackOverflow you quoted is conflicting, and really, so is this whole standard. I'd be tempted to keep T enforced less this library start supporting any separator value unless you've found a case of this in the wild?

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