Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

There are many possible valid ISO date formats #827

Closed
thadguidry opened this issue Dec 3, 2024 · 0 comments
Closed

There are many possible valid ISO date formats #827

thadguidry opened this issue Dec 3, 2024 · 0 comments
Labels
enhancement New feature or request epic Collection of issues

Comments

@thadguidry
Copy link
Collaborator

There are many possible valid ISO date formats. We can add a few more of these also where the dialects have support out-of-the-box, and adjust test response expectations accordingly for each dialect (since many of these tests will fail without EDTF extension support in the database):

  • 1999.008 valid year and date in PostgreSQL
  • J2451187 valid Julian date in PostgreSQL
  • January 8, 99 BC valid year 99 BC in PostgreSQL
  • 040506 valid ISO 8601 Time input in PostgreSQL
  • 040506+07:30:00 valid UTF offset specified to seconds (not allowed in ISO 8601) but valid Time input in PostgreSQL
  • infinity valid special Date/Time input in PostgreSQL which is internally represented as math ∞ but displayed as infinity.
  • allballs special Date/Time input in PostgreSQL that represents new day in UTC 00:00:00.00 UTC
  • Reduced precision: 2019-12
  • Ordinal Date: 2024-336 this depends on the installation config of some DB's but it's generally supported.
  • UTC: T144515Z

Repeating intervals might also be stored? but I think this is only special DB modes and like T-SQL.

  • R5/2008-03-01T13:00:00Z/P1Y2M10DT2H30M
  • P1Y2M10DT2H30M a valid interval in PostgreSQL and others support intervals
    • time, timestamp, and interval accept an optional precision value p which specifies the number of fractional digits retained in the seconds field. By default, there is no explicit bound on precision. The allowed range of p is from 0 to 6.

These are Extended Date Time Formats, but most are not supported in regular modes with the dialects

  • 1964/2008 is a time interval with calendar year precision, beginning sometime in 1964 and ending sometime in 2008.
  • Y-170000002 is the year -170000002
  • 2001-21 is Spring, 2001 (values of 21,22,23,24 signify 'Spring', 'Summer', 'Autumn', 'Winter' and found sometimes in edge network monitoring stations and scientific datasets.
  • 2004-06-11% is a year-month-date with uncertainty and approximation.
  • 1988/.. open end time interval starting at year 1985 with year precision and open ending.
  • /1988 unknown start and ending year 1985.
  • 1950S2 represents some year between 1900 and 1999, estimated to be 1950
  • 156X-12-25 December 25 sometime during the 1560s.

ERRORS:
-1985 ISO 8601 Part 1 does not support negative years.

Originally posted by @thadguidry in #825 (comment)

@thadguidry thadguidry added enhancement New feature or request epic Collection of issues labels Dec 3, 2024
@9tigerio 9tigerio locked and limited conversation to collaborators Dec 10, 2024
@kdhrubo kdhrubo converted this issue into discussion #829 Dec 10, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
enhancement New feature or request epic Collection of issues
Projects
None yet
Development

No branches or pull requests

1 participant