Package maintainers and Hackage trustees are allowed to edit certain bits
of package metadata after a release, without uploading a new tarball.
Note that the tarball itself is never changed, just the metadata that is
stored separately. For more information about metadata revisions, please
refer to the
Hackage Metadata Revisions FAQ.
| No. |
Time |
User |
SHA256 |
| -r3 (time-interval-0.1.0.0-r3) |
2015-10-05T14:03:19Z |
akrasner |
bb8d2204c5dcdf0a749985524cd52debe95511ad8ed785c6ab6e19e877de46ae
|
|
Changed source-repository
from source-repository head
type: darcs
location: http://dev.rel4tion.org/fr33domlover/time-interval
to source-repository head
type: darcs
location: http://hub.darcs.net/fr33domlover/time-interval
|
| -r2 (time-interval-0.1.0.0-r2) |
2015-09-10T19:36:34Z |
akrasner |
c6488aa6b8901b7b1c03f87c1f187448b9ce18dfa6e3c8eb011d57c9f38f486d
|
|
Changed category
from Web
to Data
|
| -r1 (time-interval-0.1.0.0-r1) |
2015-09-10T19:34:17Z |
akrasner |
781da8811d238513ac877acadebca7a86d428fe0a55380c2e51c43db1b98bbfe
|
|
Changed description
from Two common ways to represent and hold short time intervals seem to be:
1. Hold time in microseconds as an 'Int' or 'Integer'
2. Use time units abstraction, e.g. see the time-units package
While the second option is a great abstraction to use in APIs, it works for
datatypes a bit less well than for function types. That's because a datatype
which a 'Data.Time.Units.TimeUnit' field suddenly becomes polymorphic over
that field, and all function type signatures involving that datatype need to
be updated. This is less an issue for functions, because you don't specify
the type of every function at the call site.
Perhaps there is a solution for that which involves datatype related
language extensions, but this package tries to offer a simple clean solution
as follows. You store time in your datatype as an integer, but it is wrapped
by an opaque 'Data.Time.Interval.TimeInterval' type. You then get the best of
both worlds:
* On one hand, you can set the time field using any time unit thanks to the
time-units package, so you get a nice abstraction
* On the other hand, your datatype holds a concrete time type
The time type can be equally used to represent time intervals, time durations
and generally time lengths. But since high precision is used (microseconds),
you'll probably want this library for short time lengths (at most seconds,
minutes, hours). For calendar based and related time functions and types, see
the @time@ package.
to Two common ways to represent and hold short time intervals seem to be:
1. Hold time in microseconds as an 'Int' or 'Integer'
2. Use time units abstraction, e.g. see the time-units package
While the second option is a great abstraction to use in APIs, it works for
datatypes a bit less well than for function types. That's because a datatype
which a 'Data.Time.Units.TimeUnit' field suddenly becomes polymorphic over
that field, and all function type signatures involving that datatype need to
be updated. This is less an issue for functions, because you don't specify
the type of every function at the call site.
Perhaps there is a solution for that which involves datatype related
language extensions, but this package tries to offer a simple clean solution
as follows. You store time in your datatype as an integer, but it is wrapped
by an opaque 'Data.Time.Interval.TimeInterval' type. You then get the best of
both worlds:
* On one hand, you can set the time field using any time unit thanks to the
time-units package, so you get a nice abstraction
* On the other hand, your datatype holds a concrete time type
The time type can be equally used to represent time intervals, time durations
and generally time lengths. But since high precision is used (microseconds),
you'll probably want this library for short time lengths (at most seconds,
minutes, hours). For calendar based and related time functions and types, see
the @time@ package.
|
| -r0 (time-interval-0.1.0.0-r0) |
2015-09-10T19:33:04Z |
akrasner |
06d67cb3a9800d0341c7f9dd97df43934ad153ef700bf268b7b10ed0f5a39935
|
|
|