Dear Juanma,
thanks for your remarks.
Juanma Barranquero (Mon, Nov 10, 2003 at 10:54:22AM +0100):
On Fri, 7 Nov 2003 19:55:47 +0100
Stefan Karrmann [EMAIL PROTECTED] wrote:
I've inserted 'convert = (uncurry cFromTai) . cToTai'.
Great, thanks.
A fixed and checked version is appended
On Fri, 7 Nov 2003 19:55:47 +0100
Stefan Karrmann [EMAIL PROTECTED] wrote:
I've inserted 'convert = (uncurry cFromTai) . cToTai'.
Great, thanks.
A fixed and checked version is appended and carbon copied to
[EMAIL PROTECTED].
What's haskell-libs-developers? I thought libraries'
Dear Juanma,
some last moment changes broke the library, I am sorry.
Juanma Barranquero (Thu, Nov 06, 2003 at 05:03:03PM +0100):
On Sat, 1 Nov 2003 17:36:11 +0100
Stefan Karrmann [EMAIL PROTECTED] wrote:
a while ago time calculation was subject on this list.
Now, I have a
On Sat, 1 Nov 2003 17:36:11 +0100
Stefan Karrmann [EMAIL PROTECTED] wrote:
a while ago time calculation was subject on this list.
Now, I have a time library based on the TAI (international
atomic time) time scale.
I get the following error with GHCi:
Stefan Karrmann [EMAIL PROTECTED] writes:
a while ago time calculation was subject on this list.
Now, I have a time library based on the TAI (international
atomic time) time scale.
This is cool! But what actually happens when people post interesting
library code to the list? Does somebody
Hi,
a while ago time calculation was subject on this list.
Now, I have a time library based on the TAI (international
atomic time) time scale.
Peter Thiemann (Thu, Feb 06, 2003 at 12:40:14PM -0800):
John's code illustrates TimeDiff's deficiencies perfectly:
There is also a more fundamental
Peter Thiemann (Mon, Feb 10, 2003 at 04:36:17PM -0800):
Stefan == Stefan Karrmann [EMAIL PROTECTED] writes:
Stefan Peter Thiemann (Thu, Feb 06, 2003 at 12:40:14PM -0800):
John's code illustrates TimeDiff's deficiencies perfectly:
There is also a more fundamental problem
On 11 Feb 2003, at 18:23, George Russell wrote:
Add 1 month to 1st February 2003. This produces 1st March 2003. (with no
overflow.)
Here, you add 28 days, which is the number of days in (this) February. Fair
enough.
Add 1 month to 31st January 2003. Then we get 31st February 2003.
George So while I started typing this thinking it was a straight
George choice between Peter's monotonicity/invertibility and the
George fact that my system corresponds better to natural usage,
George Peter doesn't even have monotonicity or invertibility.
Yes, I also realized
Jonathan Coxhead wrote (quoting me, snipped)
Add 1 minute to 23:59:60 31st December 2003. I assume that this is a valid
time
and that it will be a leap second; if not choose some other year.
This is complicated since we have multiple overflows. First stage you get the
invalid time
23:60:60
[snip]
It is always a problem to lump things with different semantics into
the same type :-) What I'm arguing is that there should be only one
fixed-duration offset datatype and it should be in terms of (seconds,
picoseconds).
Other fixed durations can be easily defined in terms of this
Peter wrote (snipped)
As far as I read ISO8601 (which also has a notation for durations)
this is unspecifed :-) And as far as I read TimeExts.lhs it does some
sort of rollover. My take would be to specify the behavior for adding
something like a TimeDiff to a base date in a consistent manner
Stefan == Stefan Karrmann [EMAIL PROTECTED] writes:
Stefan Peter Thiemann (Thu, Feb 06, 2003 at 12:40:14PM -0800):
John's code illustrates TimeDiff's deficiencies perfectly:
There is also a more fundamental problem with the TimeDiff data
type. While seconds, minutes,
SM I wrote a reply, but I don't really have anything new to say over what's
SM been said already, so I'll keep it brief instead. The copy of ISO8601
SM that I looked at is here:
SM http://www.astroclark.freeserve.co.uk/iso8601/index.htm, but from what
SM you said I'm guessing
George OK, what TimeExts does, I hope, is add the appropriate amount of the
appropriate
George time unit (whatever it is) directly, then rely on the CalendarTime
conversions to
George resolve any overflows. This probably isn't very clear,
George so I'll give some examples of
Peter Thiemann wrote:
George OK, what TimeExts does, I hope, is add the appropriate amount of the
appropriate
George time unit (whatever it is) directly, then rely on the CalendarTime
conversions to
George resolve any overflows. This probably isn't very clear,
George so
SM TimeDiff isn't a duration, it's a way of specifying time offsets whose
SM duration depends on the base to which the offset is being added. If we
SM only had constant-duration offsets, then there would be no way to say
SM give me a ClockTime for this time next Wednesday.
Peter Thiemann (Thu, Feb 06, 2003 at 12:40:14PM -0800):
John's code illustrates TimeDiff's deficiencies perfectly:
There is also a more fundamental problem with the TimeDiff data
type. While seconds, minutes, hours, and days are clearly specified
amounts of time, the duration of a month or a
Peter Thiemann (Fri, Feb 07, 2003 at 10:22:12AM -0800):
SM == Simon Marlow [EMAIL PROTECTED] writes:
SM This isn't a problem with the spec, I think. A TimeDiff of 1 month is
SM precisely a difference, which, when added to a given ClockTime, produces
SM a ClockTime which is one
SM TimeDiff has a perfectly well-defined meaning for Eq
and Ord: one
SM TimeDiff is equal to another iff all the fields are
respectively equal.
Yes, sure, Eq and Ord are defined by
deriving (Eq, Ord, ...)
but this does not make much sense if the representation for a
Matthew Donadio (Fri, Feb 07, 2003 at 01:13:30PM -0500):
Pretty much the whole world runs on UTC. All of the common time
distribution systems use UTC. Technically, GPS doesn't, but the GPS
signal includes the correction to UTC. I understand the argument for
using TAI. Maybe internally the
Keith Wansbrough (Thu, Feb 06, 2003 at 05:46:22PM +):
Stefan Karrmann [EMAIL PROTECTED] writes:
A sound base for a Time implementation should use TAI (temps atomique
international), c.f. http://cr.yp.to/libtai.html.
I disagree; I think UTC is quite sufficient, and will match the
Hi all,
I'm jumping into this a bit late, but I have some good info about time.
Two sites that I know about that have good tutorials and white papers
are
http://www.datum.com/res_technical.html
http://www.truetime.com/DOCSn/TTreferencematerial.html
In particlar, the paper Timing and Time Code
Matthew Donadio wrote:
Pretty much the whole world runs on UTC. All of the common time
distribution systems use UTC. Technically, GPS doesn't, but the GPS
signal includes the correction to UTC. I understand the argument for
using TAI. Maybe internally the libray should use TAI, but
SM == Simon Marlow [EMAIL PROTECTED] writes:
Ha! After playing with this, I discovered that only the seconds were
set and all other fields remained untouched. At least in ghc's
implementation. Interestingly, TimeDiff derives Eq and Ord, but I'd
better not ask for their
Simon Peyton-Jones (Mon, Feb 03, 2003 at 10:06:40AM -):
| the haskell 98 time library is horribly broken, if you are using ghc,
| you can deconstruct the time constructor which has an Integer
containing
| the number of seconds since epoch... otherwise you can use
|
...
| I dont
Stefan Karrmann [EMAIL PROTECTED] writes:
A sound base for a Time implementation should use TAI (temps atomique
international), c.f. http://cr.yp.to/libtai.html.
I disagree; I think UTC is quite sufficient, and will match the users'
expectations much better. (executive summary: UTC is the
[Keith Wansbrough [EMAIL PROTECTED]]
Stefan Karrmann [EMAIL PROTECTED] writes:
A sound base for a Time implementation should use TAI (temps atomique
international), c.f. http://cr.yp.to/libtai.html.
I disagree; I think UTC is quite sufficient, and will match the users'
expectations much
I've been running into similar problems, and I've also been pointed to
the TimeExt library that George Russell was talking about. However, in
the end, I had to implement something by myself. Much unfortunately
though, my program relies on an undocumented feature of GHC's
implementation of TimeDiff
| the haskell 98 time library is horribly broken, if you are using ghc,
| you can deconstruct the time constructor which has an Integer
containing
| the number of seconds since epoch... otherwise you can use
|
...
| I dont supose this could be considered a typo in the haskell 98
report?
| it is
Simon PJ wrote (snipped)
Meanwhile, I suspect there's an opportunity for someone (or a small
group) to suggest a new Time library that really does the business, and
provide an implementation. If it's sufficiently persuasive, all the
implementations will adopt it and it can become a de-facto
the haskell 98 time library is horribly broken, if you are using ghc,
you can deconstruct the time constructor which has an Integer containing
the number of seconds since epoch... otherwise you can use
epoch :: ClockTime
epoch = toClockTime $ CalendarTime { ctYear = 1970, ctMonth = January,
ctDay
32 matches
Mail list logo
