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

isoTimestamp only accepts UTC timestamps #495

Closed
macarie opened this issue Mar 27, 2024 · 4 comments
Closed

isoTimestamp only accepts UTC timestamps #495

macarie opened this issue Mar 27, 2024 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@macarie
Copy link
Contributor

macarie commented Mar 27, 2024

It looks like ISO_TIMESTAMP_REGEX validates only UTC timestamps (ending with Z). But the standard also defines the possibility of having offsets.

From my understanding, the following formats should all be considered as valid ISO timestamps:

  • <time>Z
  • <time>±hh:mm
  • <time>±hhmm
  • <time>±hh

If you consider it a bug, I'd happily open a PR 🙂

@fabian-hiller
Copy link
Owner

Thank you for creating this issue! Do you have a use case for this functionality? Can you share some example code?

@fabian-hiller fabian-hiller self-assigned this Mar 27, 2024
@fabian-hiller fabian-hiller added the question Further information is requested label Mar 27, 2024
@macarie
Copy link
Contributor Author

macarie commented Mar 28, 2024

@fabian-hiller, while working with a Rails backend, we get timestamps with offsets like this: 2023-08-09T18:04:15.582+02:00.

The idea was to validate the field using string([isoTimestamp()]), but the validation fails as it doesn't have the expected format (→ ending with Z).

The offset is valuable in some use cases, as it can be used to determine the event's local time without pulling data from other sources (geolocation, etc.). For example, when selling tickets for a concert in the US, just the offset would be enough to show both the event's local time and the user's local time. But this example can be extended to flights, conferences, etc.

Considering that it seems to be part of the accepted standard, I think this should be handled by the default regex.

@fabian-hiller
Copy link
Owner

Thank you for the info! Feel free to create a PR and expand the current regex.

@fabian-hiller
Copy link
Owner

Should be fixed 🙌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants