I am sorry if this is the wrong place to ask this—but I am curious if there is a changelog for this library available.

Thanks,
Jon

I get the following error:

Preprocessing test suite 'tests' for time-1.5.0.1...

test/Test/Tests.hs:16:8:
    Could not find module ‘Test.TestTimeZone’
    Use -v to see a list of the files searched for.

I suppose this means that there's a module missing from the Cabal file (and hence the release tarball).

Reproducer is the following code:

import Data.Time

main = do
    print . zonedTimeToUTC $ read "2015-05-12 18:00:00 CEST"
    print . zonedTimeToUTC $ read "2015-05-12 18:00:00 +02:00"

Running it with time-1.5.0.1 produces output (CEST is the same as +02:00)

2015-05-12 18:00:00 UTC
2015-05-12 16:00:00 UTC

this is a regression against 1.4.0.1 as with that one (on the same machine) the code (I would argue correctly) produces

2015-05-12 16:00:00 UTC
2015-05-12 16:00:00 UTC

Prelude> import Data.Time.Format
Prelude Data.Time.Format> parseTimeM True defaultTimeLocale "%H:%M:%S" "12:34:56" :: Maybe Data.Time.LocalTime.LocalTime
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package time-1.5.0.1 ... linking ... done.
Just 1970-01-01 12:34:56

However, Just 1970-01-01 12:34:56 is not a valid Haskell expression. Instead, parseTimeM ... "1970-01-01 12:34:56" would be or something that allows to construct a LocalTime. Show and Read are for formatting and parsing Haskell expressions. Text exchange for users must be done with formatTime, parseTime and friends, instead.
I guess that same problem occurs for the other time types.

CTime there is Int32.

[21 of 33] Compiling Data.Time.LocalTime.Internal.TimeZone ( lib/Data/Time/LocalTime/Internal/TimeZone.hs, dist/build/Data/Time/LocalTime/Internal/TimeZone.o )

lib/Data/Time/LocalTime/Internal/TimeZone.hs:101:48: error:
    • Couldn't match type ‘Int64’ with ‘Int32’
      Expected type: SystemTime -> Int32
        Actual type: SystemTime -> Int64
    • In the second argument of ‘(.)’, namely ‘systemSeconds’
      In the second argument of ‘(.)’, namely ‘CTime . systemSeconds’
      In the expression: getTimeZoneCTime . CTime . systemSeconds

Since this is pretty much the de-facto Haskell library for manipulating dates and times, it seems that it should provide a DayOfWeek enumeration like this:

data DayOfWeek
    = Sunday
    | Monday
    | Tuesday
    | Wednesday
    | Thursday
    | Friday
    | Saturday

What are your thoughts on adding something like this?

In testing out one of my packages with ghc 8.2 rc2, I found a failing test which I've boiled down to the following: is this a bug in time, or in ghc, or allowed behavior?

The problem is that I am trying to round-trip the string '1970-01-01T00:00:00Z' to UTCTime and then back to a string, and with time 1.8.0.1 this returns '1970-01-01T00:00:00.Z' - note the decimal point.

Details below:

% cat prob.hs
module Main where

import Data.Time
import Data.Maybe

fmt :: String
fmt = "%FT%T%QZ"

torig :: String
torig = "1970-01-01T00:00:00Z"

tconv :: UTCTime
tconv = fromJust (parseTimeM True defaultTimeLocale fmt torig)

tnew :: String
tnew = formatTime defaultTimeLocale fmt tconv

main :: IO ()
main = do
  putStrLn ("Original:  " ++ torig)
  putStrLn ("Converted: " ++ tnew)

I see the following on a ubuntu laptop

a) ghc 8.0.2, time 1.6.0.1

% ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.0.2
% ghc-pkg list time
/usr/lib/ghc/package.conf.d
    time-1.6.0.1
/home/djburke/.ghc/x86_64-linux-8.0.2/package.conf.d
    (no packages)
% runghc prob.hs
Original:  1970-01-01T00:00:00Z
Converted: 1970-01-01T00:00:00Z

b) ghc 8.2 rc2, time 1.8.0.1

% ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.2.0.20170507
% ghc-pkg list time
/home/djburke/local/ghc-8.2.0.20170507/lib/ghc-8.2.0.20170507/package.conf.d
    time-1.8.0.1
% runghc prob.hs
Original:  1970-01-01T00:00:00Z
Converted: 1970-01-01T00:00:00.Z

See the following output:

Resolving dependencies...
Configuring time-1.5.0.1...
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking for gmtime_r... yes
checking for localtime_r... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for struct tm.tm_zone... yes
checking whether time.h and sys/time.h may both be included... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking whether altzone is declared... no
configure: creating ./config.status
config.status: error: cannot find input file: `lib/include/HsTimeConfig.h.in'

This seems to be related to #3, in which it is said to be autogenerated. However, autoreconf did not do that for me.

I'm quite pleased by time 's portability(comparing to unix-time) , but the performance can be improved IMHO:

• We shouldn't create thunks during conversions, i propose mark the field of TimeOfDay, LocalTime, UTCTime with strict pragmas, some field also should be unpacked.

• We should add POSIXTimeRaw like the one from unix-time, with a CTime and Int32 field, it's faster, when year 2038 come we have to deal with this anyway.

• I'd like to add Text based formatter and parser, but that can be done in a seperate package if text is too heavy to be depended on.

It would appear that this would not be a trivial feature to add, but essentially it would be great if one could specify a width for some of the values (currently I'm thinking about displaying milliseconds truncated to 3 decimal places -- %q is just too damn long).

Although the format specifier syntax matches glibc quite well, there is this extra bit that's missing (http://linux.die.net/man/3/strftime):

An optional decimal width specifier may follow the (possibly absent) flag. If the natural size of the field is smaller than this width, then the result string is padded (on the left) to the specified width.

I haven't tracked down where things are defined, but Data.Time.Format uses months and wDays functions that return lists representing the mapping from numbers to month and day names. The obvious approach, I think, would just be to return a function from each of these instead of a list.

Looking at lib/Data/Time/Format/Parse.hs, I was surprised to see that the way parse errors are reported is through fail or error. Would you consider switching to something cleaner like mzero from MonadPlus, or throwError from MonadError ?

Is there a reason that DiffTime does not have ParseTime or FormatTime instances?

Hey all, according to #58 the version of time that will be released with GHC 8.2 will be 1.8. As such, I would quite appreciate the cutting a 1.8 branch, so we can start backporting fixes (in particular, I need the patch from that PR to fix the GHC build with the new version of Cabal.) Thanks!

Received from Zoran Bosnjak:

please consider this test program:

---
import Data.Time

main = do
    getCurrentTime >>= print
    main
---

If I let this program run for some time, it would slowly consume more and
more memory, for example:
- at program startup, it is using 4168k
- after a minute or so, it goes to 4436k
- after few more minutes it stabilizes at 4700k bytes
There is a small difference on each run, but the same observation.

Is it possible, that some dynamic memory allocation of the time library is
the reason for this?
I would appreciate if you can check it.

I am working on long running process which is not running with constant
memory as it is suppose to run. There are for sure some other reasons too,
but I think that this test program is not suppose to behave like this.

I am checking memory by running "cat /proc/<pid>/status | grep VmRSS"
My environment is linux 3.19, ghc 8.0.1.

The documentation for the format strings says

%H
hour of day (24-hour), 0-padded to two chars, 00 - 23
...
%M
minute of hour, 0-padded to two chars, 00 - 59

but while

parseTimeM True defaultTimeLocale "%Y-%m-%d %H:%M" "2017-03-31 23:59" :: Either String UTCTime
parseTimeM True defaultTimeLocale "%Y-%m-%d %H:%M" "2017-02-29 23:59" :: Either String UTCTime

Succeeds/Fails correctly, the following

parseTimeM True defaultTimeLocale "%Y-%m-%d %H:%M" "2017-03-31 23:99" :: Either String UTCTime
parseTimeM True defaultTimeLocale "%Y-%m-%d %H:%M" "2017-03-31 99:59" :: Either String UTCTime
parseTimeM True defaultTimeLocale "%Y-%m-%d %H:%M" "2017-03-31 99:99" :: Either String UTCTime

Succeed - with hours/minutes I would not consider correct.

I would expect parseTimeM to have the property "if it is parseable then the formatted string is equal to the initial string".

import Data.Time
import Test.QuickCheck
import Text.Printf

newtype YmdHMString = YmdHM String deriving Eq

instance Show YmdHMString where
  show (YmdHM s) = s

instance Arbitrary YmdHMString where
  arbitrary = do year   <- getPositive <$> (arbitrary :: Gen (Positive Integer))
                 month  <- choose (00,99) :: Gen Int
                 day    <- choose (00,99) :: Gen Int
                 hour   <- choose (00,99) :: Gen Int
                 minute <- choose (00,99) :: Gen Int
                 return $ YmdHM $ printf "%d-%02d-%02d %02d:%02d"
                                         year month day hour minute

prop_YmdHM (YmdHM s) = let fmt = "%Y-%m-%d %H:%M"
                           time = parseTimeM True defaultTimeLocale fmt s :: Maybe UTCTime
                        in maybe True ((s==).formatTime defaultTimeLocale fmt) time

Since the DiffTime part of UTCTime should be in [0,86400s] (according to its description), it requires a check to ensure that it actually is, what would be nice to abstract into a function: as @phadej suggested on haskell/aeson#500 (comment), there is a few options (including clipping, rolling over, failing).

Besides, a function (maybe a separate one though, but it may be particularly suitable for this one) that would construct time out of regular time components (hours, minutes, etc) may be handy by itself.

Another somewhat related issue, which may be fixed with this, is that parseTimeM sometimes fails to parse what formatTime printed (e.g., on 100 seconds), and sometimes prints/parses it in a way that violates the invariant (e.g., on 99 seconds). Those 61-99 seconds seem to fall under "unspecified behaviour", but perhaps it would be better to specify it in a way that at least vaguely makes sense (say, roll over, using the proposed function).

parseTime :: ParseTime t => TimeLocale -> String -> String -> Maybe t

parseTime checks the format of it's third argument (date string) using it's second (format string, for example 'YYYY-MM-DD'). However, it does not check the date's validity - instead it rounds to the closest valid date.

import System.Locale
import Data.Time
parseTime defaultTimeLocale "%Y-%m-%d" "2015-01-99" :: Maybe Day

Just 2015-01-31

What I'd like is to get a valid date, or error.

When compiling the time library ins GHC git HEAD i get a bunch of these tab warnings. GHC is now using -fwarn-tabs by default. The time library should either a) remove tabs to come into line with GHC standard practice or b) add -fno-warn-tabs to the cabal file.

Thanks!

The picosecondsToDiffTime :: Integer -> DiffTime function provides full-precision conversion of integral picoseconds to a DiffTime, but there is no reverse. This makes it difficult to use DiffTime in some code because the user has to go through toRational and then deconstruct the Rational to recover the original input value.

I propose a diffTimeToPicoseconds :: DiffTime -> Integer function be added.

Hi all,

I hope to be able to use UTCTime's (or Day's and DiffTimes) in my data types and derive Generic for those types, but at the moment, this isn't possible; I wouldn't mind doing standalone derivation, but DiffTime doesn't export its constructor, so I can't write a standalone deriving instance for that.

Are there any plans to export a Generic instance for DiffTime/UTCTime etc., or is this strictly against the spirit of the library?

Hello,

I want the UTCTime associated to a LocalTime. In order to convert a LocalTime to UTCTime, I need a TimeZone. But I can't figure out how to get the TimeZone associated to a LocalTime. In the following example, I use getTimeZone with the UTCTime constructed from the Day and TimeOfDay, but it does not relate to the same time as the LocalTime, that is why I don't get the final UTCTime I am searching for.

import Data.Time.Clock (UTCTime(..))
import Data.Time.Calendar (fromGregorian)
import Data.Time.LocalTime (LocalTime(..), TimeOfDay(..), localTimeToUTC, getTimeZone, timeOfDayToTime)

main :: IO ()
main = do
  let day = fromGregorian 2016 10 30
  let timeOfDay = TimeOfDay 1 0 0
  let localTime = LocalTime day timeOfDay
  timeZone <- getTimeZone (UTCTime day (timeOfDayToTime timeOfDay))
  let utcTime = localTimeToUTC timeZone localTime
  putStrLn (show utcTime)

It shows 2016-10-30 00:00:00 UTC but I want 2016-10-29 23:00:00 UTC. There is no problem with the time library, I just don't know how to get the correct time zone associated with my local time.

In France, on 2016-10-30 at 3 o'clock, the hour change and we get back at 2 o'clock. The time zone change from CEST to CET, the time library get this correctly:

getTimeZone (UTCTime (fromGregorian 2016 10 30) (timeOfDayToTime (TimeOfDay 0 0 0))) -- 2h in France
CEST
getTimeZone (UTCTime (fromGregorian 2016 10 30) (timeOfDayToTime (TimeOfDay 1 0 0))) -- 2h in France
CET

I would need a function:

getTimeZone :: LocalTime -> IO TimeZone

My use case for this need is I want to get UTCTime at the beginning of the current week and the previous week, for notification purposes. I successfully get local times but can't get for sure correct utc times.

Is this function missing or am I missing something ?

I'm trying to understand which breaking changes I need to look out for in time-1.8, i.e. when is it safe to upgrade to (i.e. relax upper bounds to allow) time-1.8 (IOW, when does "it compiles" equate to "it's compatible") ?

The changelog entry for 1.8 seems harmless to me, i.e. it looks merely like API additions, no real breaking changes?

[1.8]

• Added SystemTime
• Data.Time.Format: allow padding widths in specifiers for formatting (but not parsing)
• Test: use tasty, general clean-up
• Test: separate out UNIX-specific tests, so the others can be run on Windows
• Clean up haddock.

/cc @phadej @bergmark

It isn't said anywhere that reading a TimeZone is useless (since it only reads the name, leaving timeZoneMinutes empty).

Should the Read instance for TimeZone be removed? If not, then at least this behaviour should be documented and warned about.

The function formatTime can't be used since it needs a TimeLocale structure and the module where TimeLocale is defined is not in exposed-modules or re-exported in other modules that are exposed.

Version: 1.4.2

Output from ghci using :browser!:

*Application Data.Time.Format> :browse! Data.Time.Format
-- imported via Data.Time.Format
class Data.Time.Format.FormatTime t where
  formatCharacter ::
    Char
    -> Maybe
         (old-locale-1.0.0.6:System.Locale.TimeLocale
          -> Maybe Data.Time.Format.NumericPadOption -> t -> String)
formatCharacter ::
  Data.Time.Format.FormatTime t =>
  Char
  -> Maybe
       (old-locale-1.0.0.6:System.Locale.TimeLocale
        -> Maybe Data.Time.Format.NumericPadOption -> t -> String)
formatTime ::
  Data.Time.Format.FormatTime t =>
  old-locale-1.0.0.6:System.Locale.TimeLocale
  -> String -> t -> String
type Data.Time.Format.NumericPadOption = Maybe Char
class Data.Time.Format.ParseTime t where
  buildTime ::
    old-locale-1.0.0.6:System.Locale.TimeLocale
    -> [(Char, String)] -> t
buildTime ::
  Data.Time.Format.ParseTime t =>
  old-locale-1.0.0.6:System.Locale.TimeLocale
  -> [(Char, String)] -> t
Data.Time.Format.parseTime ::
  Data.Time.Format.ParseTime t =>
  old-locale-1.0.0.6:System.Locale.TimeLocale
  -> String -> String -> Maybe t
readTime ::
  Data.Time.Format.ParseTime t =>
  old-locale-1.0.0.6:System.Locale.TimeLocale
  -> String -> String -> t
readsTime ::
  Data.Time.Format.ParseTime t =>
  old-locale-1.0.0.6:System.Locale.TimeLocale -> String -> ReadS t

I'm getting this linking error when building ghc-mod using stackage lts-8.4:

Linking .stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build/ghc-mod/ghc-mod ...
    Undefined symbols for architecture x86_64:
      "_timezm1zi6zi0zi1_DataziTimeziClockziCTimespec_getCTimespec1_closure", referenced from:
          _SigH_srt in libHSrandom-1.1-9tceXaeYIMZ4JrKq20Egog.a(Random.o)
      "_timezm1zi6zi0zi1_DataziTimeziClockziCTimespec_getCTimespec1_info", referenced from:
          _cikh_info in libHSrandom-1.1-9tceXaeYIMZ4JrKq20Egog.a(Random.o)
    ld: symbol(s) not found for architecture x86_64
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    `gcc' failed in phase `Linker'. (Exit code: 1)

Is it because of the #if macro in:
lib/Data/Time/Clock/Internal/CTimespec.hsc:#if !defined(mingw32_HOST_OS) && HAVE_CLOCK_GETTIME
?

Somehow time is built without a symbol that random is expecting. I am doing it on osx 10.12.3 (sierra). Is that symbol supposed to be missing on my system?

just tried to install time-1.6 with ghc-7.10.3

got:

cabal: The following packages are likely to be broken by the reinstalls:
process-1.2.3.0
ghc-7.10.3
Cabal-1.22.5.0
haskeline-0.7.2.1
directory-1.2.2.0
hpc-0.6.0.2
bin-package-db-0.0.0.0

any suggestions?

getCurrentTime (which is defined in terms of getPOSIXTime) currently returns timestamps with microsecond resolution. Modern unices on the the other hand support nanosecond resolution timestamps via the call clock_gettime(CLOCK_REALTIME). It would be nice if time supported that.

I would be happy to provide a pull request. It will require adding an hsc file.

I'm willing to submit a pull request to replace all Strings with Texts, will you accept it ?

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 like fromGregorian which interface with Integers. 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, better Storable 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 using fromIntegral to interface with the API anyways, and this change will actually lessen the amount of marshalling people need to do.

Can I ask why the dependency on base is >= 4.8?

ZonedTime is missing an instance of Eq. It seems that converting to UTC and comparing would be the correct implementation.

> parseTimeM True defaultTimeLocale "%Y-%m-%d %H:%M:%S %Z" "2017-01-28 10:11:11 EDT" :: Maybe UTCTime
Just 2017-01-28 14:11:11 UTC
> parseTimeM True defaultTimeLocale "%Y-%m-%d %H:%M:%S %Z" "2017-01-28 10:11:11 eastern" :: Maybe UTCTime
Just 2017-01-28 10:11:11 UTC

This is documented behavior but doesn't make sense to me: after all you have a list of zone names in the TimeLocale I just passed in. In any case this makes the function with %Z pretty useless.

The same sort of complaint as #70

A lot of tests are failing on 32-bit Linux, because the time_t type is only 32 bits. I don't believe that the failures indicate defects, but it would be good to clear them up anyway.

In short: the Show instance for UTCTime doesn't come into scope when Data.Time.Clock is imported. The haddocks claim that it will. This is confusing.

The haddocks for UTCTime claim the existence of a Show instance: http://hackage.haskell.org/package/time-1.5/docs/Data-Time-Clock.html

And indeed I was using getCurrentTime >>= print in a piece of code and it was working.

Then the following happened.

$ ghci
GHCi, version 7.8.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> import Data.Time.Clock
Prelude Data.Time.Clock> getCurrentTime >>= print

<interactive>:3:20:
    No instance for (Show UTCTime) arising from a use of ‘print’
    In the second argument of ‘(>>=)’, namely ‘print’
    In the expression: getCurrentTime >>= print
    In an equation for ‘it’: it = getCurrentTime >>= print

Then I checked my old code which worked. It has a bunch of seemingly unrelated imports. A few minutes of uncommenting the imports one by one, I noticed when I import System.Directory the Show instance comes into scope.

$ ghci
GHCi, version 7.8.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> import Data.Time.Clock
Prelude Data.Time.Clock> import System.Directory ()
Prelude Data.Time.Clock System.Directory> getCurrentTime >>= print
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package old-locale-1.0.0.6 ... linking ... done.
Loading package time-1.4.2 ... linking ... done.
2014-10-22 09:07:14.838338 UTC

It seems this instance is defined in Data.Time.LocalTime.LocalTime.

Prelude Data.Time.Clock System.Directory> :i UTCTime
data UTCTime
  = UTCTime {utctDay :: time-1.4.2:Data.Time.Calendar.Days.Day,
             utctDayTime :: DiffTime}
    -- Defined in ‘time-1.4.2:Data.Time.Clock.UTC’
instance Eq UTCTime -- Defined in ‘time-1.4.2:Data.Time.Clock.UTC’
instance Ord UTCTime -- Defined in ‘time-1.4.2:Data.Time.Clock.UTC’
instance Read UTCTime
  -- Defined in ‘time-1.4.2:Data.Time.Format.Parse’
instance Show UTCTime
  -- Defined in ‘time-1.4.2:Data.Time.LocalTime.LocalTime’

The orphan instance can be seen from: http://hackage.haskell.org/package/time-1.5/docs/src/Data-Time-LocalTime-LocalTime.html

Moving the instance back to Data.Time.Clock probably creates cyclic imports. There must be a solution involving a few internal modules, I suppose.

In any case the haddocks are definitely misleading.

(I now I have used time-1.4.2 above, but the same problem exists in time-1.5 too)

ISO8601 / RFC 339 has supports relative times (durations), quoting:

Durations:

   dur-second        = 1*DIGIT "S"
   dur-minute        = 1*DIGIT "M" [dur-second]
   dur-hour          = 1*DIGIT "H" [dur-minute]
   dur-time          = "T" (dur-hour / dur-minute / dur-second)
   dur-day           = 1*DIGIT "D"
   dur-week          = 1*DIGIT "W"
   dur-month         = 1*DIGIT "M" [dur-day]
   dur-year          = 1*DIGIT "Y" [dur-month]
   dur-date          = (dur-day / dur-month / dur-year) [dur-time]

   duration          = "P" (dur-date / dur-time / dur-week)

It would be nice if time could parse these.

    Process exited with code: ExitFailure 1
    Logs have been written to: /home/me/Code/NOT_MY_CODE/time/.stack-work/logs/time-1.8.0.3.log

    [1 of 2] Compiling Main             ( /home/me/Code/NOT_MY_CODE/time/Setup.hs, /home/me/Code/NOT_MY_CODE/time/.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/setup/Main.o )
    [2 of 2] Compiling StackSetupShim   ( /home/me/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /home/me/Code/NOT_MY_CODE/time/.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/setup/StackSetupShim.o )
    Linking /home/me/Code/NOT_MY_CODE/time/.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/setup/setup ...
    Configuring time-1.8.0.3...
    Warning: The 'build-type' is 'Configure' but there is no 'configure' script.
    You probably need to run 'autoreconf -i' to generate it.
    setup: configure script not found.

Version 1.4.0, Git revision e714f1dd3fade19496d91bd6a017e435a96a6bcd (4640 commits) x86_64 hpack-0.17.0

This commit appears to have broken some tests in the GHC test suite a22e848 on Windows:

=====> T7702(normal) 2755 of 4088 [0, 26, 0] 
cd ./simplCore/should_compile && $MAKE -s --no-print-directory -C T7702plugin package.T7702
cd ./simplCore/should_compile && 'C:/cygwin64/home/ghc/ghc-hvr/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7702.hs  -v0 -package-db T7702plugin/pkg.T7702/local.package.conf -fplugin T7702Plugin -package T7702plugin -static +RTS -V0 -tT7702.comp.stats --machine-readable -RTS  >T7702.comp.stderr 2>&1
Compile failed (status 256) errors were:
ghc-stage2.exe: unable to load package `time-1.5'
ghc-stage2.exe: C:\cygwin64\home\ghc\ghc-hvr\libraries\time\dist-install\build\HStime_HGs4JcQCd4wF6U8vJQ5fNH.o: unknown symbol `tzset'

I'm not sure what the precise bug is.

Open this issue to track the idea of improving formatTime/TimeFormat, initial work can be reviewed here: https://github.com/winterland1989/time/blob/new-format/lib/Data/Time/Format/Part.hs . Early benchmark showed we can format TimeOfDay within 1us, the overall goal is to format LocalTime within 3us which matches unix-time 's speed(which is FFI with strftime speed). The speed goal has been reached.

benchmarking new/formatParts@LocalTime
time                 2.892 μs   (2.852 μs .. 2.928 μs)
                     0.999 R²   (0.998 R² .. 0.999 R²)
mean                 2.884 μs   (2.851 μs .. 2.917 μs)
std dev              112.2 ns   (93.78 ns .. 137.4 ns)
variance introduced by outliers: 51% (severely inflated)

benchmarking new/formatParts@TimeOfDay
time                 574.9 ns   (570.4 ns .. 580.1 ns)
                     0.999 R²   (0.999 R² .. 1.000 R²)
mean                 571.8 ns   (566.6 ns .. 576.7 ns)
std dev              16.59 ns   (13.53 ns .. 21.17 ns)
variance introduced by outliers: 41% (moderately inflated)

The idea i'm working on is that we should have an intermedia Part list that format string can be compiled to. It should be eaiser for writing different backends, such as default String based one, or maybe Text based one.

BTW, Can you transfer time-extras(seemed abandoned) package name to me? I'd like to use it as a start to write Text based formatter/parser ; )

I haven't looked into this, but I'm sure this is due to something like:

badShow n | 0 > n = "-" ++ badShow (negate n)
          | otherwise = -- this is never reached when n = minBound

which is incorrect for minBound in two's complement. Fun fact: I just reported this same bug in a completely unrelated package today.

This brings up the broader question of what really time is supposed to be doing in the case of values which (arguably) shouldn't be representable. In some cases time operations work as you'd expect, even though the intermediate values "overflow", etc.

http://hackage.haskell.org/package/time-1.6 is missing Haddock doc links.

How come mondayStartWeek returns year as Int and fromMondayStartWeek accepts year as an Integer?

https://www.stackage.org/haddock/lts-7.14/time-1.6.0.1/Data-Time-Calendar-OrdinalDate.html#v:mondayStartWeek vs https://www.stackage.org/haddock/lts-7.14/time-1.6.0.1/Data-Time-Calendar-OrdinalDate.html#v:fromMondayStartWeek

The W3C Datetime format (https://www.w3.org/TR/NOTE-datetime) wants the timezone to be formatted as "+01:00". I didn't see any way to make the format functions in this package output that format. It looks like only "+0100" is possible. It would be nice to also support the "+01:00" format.

Since the Data.Time.Calendar.OrdinalDate module comment is "ISO 8601 Ordinal Date format", I would expect it to provide a function to get the ISO week, but even mondayStartWeek uses the US definition.

isoWeek and fromIsoWeek functions would be highly appreciated. isoWeek would probably need to return the year, too, because it might be different from the argument's year.

ZonedTime is (LocalTime, TimeZone) and both of those have Eq, so this should be a simple matter of adding a deriving entry.

The time library does not allow one to represent the end of a day. ISO-8601 time has a representation for this: 24:00:00 is a time representing midnight as the end of the day, rather than the beginning.

This has come up in some of the work I do professionally. I'd like to know what is possible, especially whether the time library can be enhanced to represent this time.

Simon Hengel in https://ghc.haskell.org/trac/ghc/ticket/9962 reports:

Show instance for UTCTime is orphan

When I was doing some API calling with Haskell, I found that there is some different in UTC time representation between the Java/Python ones and the Haskell one using the time package. The Java/Python ones will also have a "Z" has suffix.

According to wikipedia, it seems like there is really some story involved.

However, I am not sure if it is really reasonable and worrying that there might be old dependency broken by adding a "Z".