-
Notifications
You must be signed in to change notification settings - Fork 684
Date and Time representations are inconsistent, leading to ambiguity #4754
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
Comments
Hi, I would like to try and work on this task. Does this just consist of going through all of the files and finding anywhere where dates exist and changing them with a more clear format? And if so how would I know which files to look at specifically which do contain dates. I am sorry I am new and would like to contribute to this project. Thanks for the help! |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Bug remains |
Can you provide more details where would you expect ISO date string ? In the meanwhile i've crated this PR #6013 |
The execution log is not in ISO format |
The submit in the trace log is not in ISO format |
The duration is not in ISO format: |
Bug report
The current implementations of human-readable dates and times are ambiguous in terms of their timezone, and in the case of durations, difficult to properly parse.
Expected behavior and actual behavior
Current dates are ambiguous of timezone:
2024-02-16 02:22:56.668
Should be
2024-02-16T02:22:56.668-05:00
(in my case Eastern)or universal time
2024-02-16T07:22:56.668+00:00
https://en.wikipedia.org/wiki/ISO_8601
Similarly, durations, such as in the trace report:
5h 50m 9s
Should use the duration format of ISO
https://en.wikipedia.org/wiki/ISO_8601#Durations
PT5H50M9S
Or the alternative, perhaps more familiar
PT05:50:09
Steps to reproduce the problem
Observe existing date/time representations
N/A
Environment
Additional context
Implementation shouldn't be too hard as I think these are all human-readable outputs and not used internally, but existing libraries should have proper formatting options already available here.
The text was updated successfully, but these errors were encountered: