-
Notifications
You must be signed in to change notification settings - Fork 82
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
Use fixed-width integers to represent days #68
Milestone
Comments
Something like charles-cooper@404f094. To get a sense of practicality I was able to get ghc to build (https://github.com/charles-cooper/ghc/tree/day_int32) with only one change to libraries/Cabal: diff --git a/Cabal/Distribution/Simple/SrcDist.hs b/Cabal/Distribution/Simple/SrcDist.hs
index 90a6323..a0b5e0e 100644
--- a/Cabal/Distribution/Simple/SrcDist.hs
+++ b/Cabal/Distribution/Simple/SrcDist.hs
@@ -391,10 +391,10 @@ snapshotVersion date = alterVersion (++ [dateToSnapshotNumber date])
-- For example given a date @18/03/2008@ produce the number @20080318@.
--
dateToSnapshotNumber :: UTCTime -> Int
-dateToSnapshotNumber date = case toGregorian (utctDay date) of
+dateToSnapshotNumber date = fromIntegral $ case toGregorian (utctDay date) of
(year, month, day) ->
- fromIntegral year * 10000
- + month * 100
+ fromIntegral{-backwards compat time-}year * 10000
+ + month * 100
+ day Which needs an extra |
It's about 6 million years each way, which is probably reasonable.
|
#80 is the larger issue. |
bgamari
pushed a commit
to bgamari/time
that referenced
this issue
Mar 27, 2024
bgamari
pushed a commit
to bgamari/time
that referenced
this issue
Mar 27, 2024
And fix free-bug in 'putEnv'. Fixes haskell#68
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently https://hackage.haskell.org/package/time-1.8.0.1/docs/Data-Time-Calendar.html#t:Day is represented in memory as an
Integer
, and many similar functions likefromGregorian
which interface withInteger
s. While this is admirably future-proof (we can deal with years larger than the year 2,147,481,790 AD!) I think we will be using intuitionistic type theory sooner than we will need those dates :)Using something like
Int32
would give us nearly the same flexibility, betterStorable
instances, interfacing with C and serialization/deserialization. I'm not sure how much this will break downstream code, but I have a feeling most people are usingfromIntegral
to interface with the API anyways, and this change will actually lessen the amount of marshalling people need to do.The text was updated successfully, but these errors were encountered: