Zefram writes:
> Probing the TAI-to-UTC conversion offered by srfi-19's time-tai->date,
> in the minutes around the leap second in 2012:
>
> scheme@(guile-user)> (use-modules (srfi srfi-19))
> scheme@(guile-user)> (for-each (lambda (d) (write (list d
> (date->string (time-tai->date (add-duration
Zefram writes:
> time-utc->date seems to think that a leap second occurs at a different
> time in each time zone:
>
> scheme@(guile-user)> (use-modules (srfi srfi-19))
> scheme@(guile-user)> (define (tdate d) (write (list (date->string d "~4")
> (date->string (time-utc->date (date->time-utc d) 3
Zefram writes:
> The manual says, in the section "SRFI-19 Introduction",
>
> #Also, for those not familiar with the terminology, a "Julian Day" is
> # a real number which is a count of days and fraction of a day, in UTC,
> # starting from -4713-01-01T12:00:00Z, ie. midday Monday 1 Jan 4713 B.
tags 22033 + notabug
close 22033
thanks
Hi Zefram,
Zefram writes:
> I wrote:
>> These two seconds are perfectly
>>distinct parts of the UTC time scale, and the time-utc format ought to
>>preserve their distinction.
>
> This is a problematic goal. At the time I
Zefram writes:
> Guile ought to be aware of how far its leap table extends, and signal
> an error when asked to perform a TAI<->UTC conversion that falls outside
> its scope.
I sympathize with your preference to raise an error rather than return
invalid results, but unfortunately I don't think t
Zefram writes:
> With Guile 2.0.11:
>
> scheme@(guile-user)> (ash 123 (ash -1 63))
> $1 = 123
Fixed in commit 1990aa916382d0afcebd5315a6d6f555949ff654 on the
stable-2.2 branch. Closing this bug now.
Thanks very much for finding this subtle bug.
Mark
Zefram writes:
> The date->string function from (srfi srfi-19), used on ISO 8601 formats
> "~1", "~4" and "~5", for years preceding AD 1, has an off-by-one error:
>
> scheme@(guile-user)> (use-modules (srfi srfi-19))
> scheme@(guile-user)> (date->string (julian-day->date 0 0) "~4")
> $1 = "-4714-
Zefram writes:
> scheme@(guile-user)> (date->string (julian-day->date 1722000 0) "~1")
> $4 = "2-07-29"
> scheme@(guile-user)> (date->string (julian-day->date 173 0) "~1")
> $5 = "24-06-23"
> scheme@(guile-user)> (date->string (julian-day->date 200 0) "~1")
> $6 = "763-09-18"
This partic
Zefram writes:
> For year numbers 1 and above, it is necessary to use more than four
> digits for the year, and that's permitted, but ISO 8601 requires that
> more than four digits are preceded by a sign. For positive year numbers
> the sign must be "+". So one should write "+22666" rather
Mark H Weaver writes:
> Zefram writes:
>
>> The date->string function from (srfi srfi-19), used on ISO 8601 formats
>> "~1", "~4" and "~5", for years preceding AD 1, has an off-by-one error:
>>
>> scheme@(guile-user)> (use-modules (srfi srfi-19))
>> scheme@(guile-user)> (date->string (julian-day
Zefram writes:
> scheme@(guile-user)> (use-modules (srfi srfi-19))
> scheme@(guile-user)> (julian-day->date 0 0)
> $1 = # year: -4714 zone-offset: 0>
> scheme@(guile-user)> (julian-day->date -1 0)
> $2 = # year: -4714 zone-offset: 0>
> scheme@(guile-user)> (julian-day->date -10 0)
> $3 = # ye
Mark H Weaver writes:
> Another question is whether or not we should raise an exception when
> attempting to print a year that cannot be represented in the requested
> year format.
I thought about it some more, and I'm now inclined to think that the
approach in your patches is reasonable, or at l
Mark H Weaver writes:
> Mark H Weaver writes:
>
>> Zefram writes:
>>
>>> The date->string function from (srfi srfi-19), used on ISO 8601 formats
>>> "~1", "~4" and "~5", for years preceding AD 1, has an off-by-one error:
>>>
>>> scheme@(guile-user)> (use-modules (srfi srfi-19))
>>> scheme@(guil
13 matches
Mail list logo
