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 milliseconds with ISO8601DurationSerializer #1231

Open
solwey-wes opened this issue Apr 14, 2023 · 3 comments
Open

Support milliseconds with ISO8601DurationSerializer #1231

solwey-wes opened this issue Apr 14, 2023 · 3 comments

Comments

@solwey-wes
Copy link

solwey-wes commented Apr 14, 2023

Per https://stackoverflow.com/questions/27058529/iso-8601-duration-with-milliseconds

Use case - EdgeDB outputs ISO 8601 duration values with decimal values for millisecond precision (and doesn't currently have a DSL function to convert to milliseconds since epoch). I can address with them or write something custom but I figure an update to the bundled serializer would be the best solution :)

'PT9.977S'
https://www.edgedb.com/docs/stdlib/datetime#function::std::duration_get

@dave26199
Copy link

Changing a serializer is a breaking change so it would have to be optional; I suggest you start with something custom and we can later add it here if there is more interest. Thanks :)

@solwey-wes
Copy link
Author

solwey-wes commented Apr 15, 2023

@dave26199 Oki will do. I was gonna ask how this would be breaking ‘cause de/serialization of existing values would function exactly as before, but I think I get it…consumers might be implicitly casting to seconds and relying on systems that assume that exact fidelity without decimals/commas. But if so, it seems those systems function in spite of ISO spec…which exists to minimize these compatibility issues. A strange loop 👀.

Either way I seem to be the only one who has bumped into this so happy to chip away at it and submit a PR so it’s here if more come along :)

@dave26199
Copy link

It's more the serialization side I was worried about, writing a different string can definitely be breaking :) but different deserialization is also a behavior change even if it seems more correct.

Sounds good, thanks.

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