Relax time upper bound to < 1.17 - #438
Merged
Merged
Conversation
Allows time-1.14, 1.15, and 1.16. These releases are additive or bugfix-level for esqueleto's purposes: esqueleto's only direct use of time is the UTCTime type, and everything else flows through persistent's serialization. The SQLite and PostgreSQL test suites pass against time-1.14, 1.15, 1.16, and 1.16.0.1 (including now_ and date_trunc round-trips). time 1.16.x currently needs allow-newer: *:time upstream (time-compat, text-iso8601, aeson still cap at < 1.16), but esqueleto itself is ready. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
parsonsmatt
force-pushed
the
matt/allow-time-1.14
branch
from
August 18, 2026 03:23
63ef58e to
e5b4ff0
Compare
|
Thank you I came here to say this... |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Relaxes the
timeupper bound from<=1.13to<1.17, admitting every releasedtimeversion (1.14, 1.15, 1.16, 1.16.0.1), and bumps the version to 3.6.0.3.All of these need
base >= 4.19, so they're only reachable on GHC 9.8+; older GHCs keep solving with oldertimeunder the unchanged lower bound.What changed in time 1.14–1.16.0.1
Lift/Genericinstances,Show CalendarDiffTimefix, maximal-munch parsing (%q/%Q, optional timezone forUTCTime, ISO8601 optionals)Data.Time.Format.Internal(nothing in esqueleto's dep tree used it)periodIn, GHC 9.14 support,template-haskell-liftforLifton 9.14+esqueleto's only direct use of
timeis theUTCTimetype (Database.Esqueleto.PostgreSQL.now_); everything else flows through persistent's serialization, so the parsing changes were the thing to smoke out against real databases.Testing
Each version pinned via
constraints:and exercised in turn:The PostgreSQL runs include
now_(parses a live server timestamp intoUTCTime) and thedate_truncround-trip tests. The 2 pending tests everywhere are the long-standing composite-PK pendings, unrelated to time.* time 1.16.x is not yet solvable in the wild without
allow-newer: *:time—time-compat,text-iso8601, andaesonstill captime < 1.16. They all compile and pass against 1.16.x under allow-newer, so this is just waiting on routine Hackage revisions upstream;<1.17means esqueleto is already ready when they land. time 1.14 and 1.15 solve with no allow-newer at all (persistent 2.18.1.0 and friends already accept them).Other notes:
mysql-0.2.1's customSetup.hsdoesn't compile against Cabal ≥ 3.14 (why 9.12 is commented out of the CI matrix). The library builds clean there.🤖 Generated with Claude Code