On Thu 2008-02-14T22:16:59 +, Poul-Henning Kamp hath writ:
> In message <[EMAIL PROTECTED]>, Steve Allen writes:
> >That's what they said about changing the conventional longitudes of
> >every observatory on the planet in order to get agreement on the value
> >of UT starting in 1962. But in 19
In message <[EMAIL PROTECTED]>, Steve Allen writes:
>> In 1961, the task was on a few handfulls of scientific people, most,
>> if not all, of them phd's, and all of them very much at home in the
>> subject domain.
>>
>> Fiddling with time_t today would involves more than a million
>> persons, very
In message: <[EMAIL PROTECTED]>
"Poul-Henning Kamp" <[EMAIL PROTECTED]> writes:
: In message <[EMAIL PROTECTED]>, Steve Allen writes:
:
: >> In 1961, the task was on a few handfulls of scientific people, most,
: >> if not all, of them phd's, and all of them very much at home in the
: >
although naive math is, well, naive, more code exists that assumes,
for example, that midnight it time_t % 86400 == 0 than you want to
believe. Changing this is really bad karma.
The current situation is that code like your example does not accurately
reflect reality. I advocate changing the
On Fri 2008-03-28T11:42:25 +, Poul-Henning Kamp hath writ:
> Simply not true. A good place to start is the FreeBSD ports-tree
> which contains about 18000 piece of open source software.
Is there a detailed inventory of how many of those break in 2038?
And how many break as binaries vs. how ma
On Fri, 28 Mar 2008, Greg Hennessy wrote:
>
> > although naive math is, well, naive, more code exists that assumes,
> > for example, that midnight it time_t % 86400 == 0 than you want to
> > believe. Changing this is really bad karma.
>
> The current situation is that code like your example does n
On Fri 2008-03-28T15:28:53 +, Tony Finch hath writ:
> The POSIX standard guarantees that what Warner wrote is correct.
The POSIX standard is in denial about leap seconds with respect to
UTC. I don't know about international standards, but in people I'm
sure that's not a good sign, and I try t
On Fri 2008-03-28T06:28:27 -0600, M. Warner Losh hath writ:
> although naive math is, well, naive, more code exists that assumes,
> for example, that midnight it time_t % 86400 == 0 than you want to
> believe. Changing this is really bad karma.
Except that the current POSIX standard is also bad k
In message <[EMAIL PROTECTED]>, Steve Allen writes:
>On Fri 2008-03-28T11:42:25 +, Poul-Henning Kamp hath writ:
>> Simply not true. A good place to start is the FreeBSD ports-tree
>> which contains about 18000 piece of open source software.
>
>Is there a detailed inventory of how many of those
In message <[EMAIL PROTECTED]>, Steve Allen writes:
>On Fri 2008-03-28T15:28:53 +, Tony Finch hath writ:
>> The POSIX standard guarantees that what Warner wrote is correct.
>
>The POSIX standard is in denial about leap seconds with respect to
>UTC. I don't know about international standards, b
On Fri 2008-03-28T16:04:49 +, Poul-Henning Kamp hath writ:
> My personal preference would be to bite the bullet and live with
> the 128bit memory hit:
>
> utc_t 64i.64f (big enough, small enough)
Whereas I am not against the notion of such, I find that nomenclature
to b
Steve Allen scripsit:
> The POSIX standard is in denial about leap seconds with respect to
> UTC. I don't know about international standards, but in people I'm
> sure that's not a good sign, and I try to avoid such.
Not exactly. What it denies is that there is necessarily 1s between
values of t
In message <[EMAIL PROTECTED]>, Steve Allen writes:
>On Fri 2008-03-28T16:04:49 +, Poul-Henning Kamp hath writ:
>> My personal preference would be to bite the bullet and live with
>> the 128bit memory hit:
>>
>> utc_t 64i.64f (big enough, small enough)
>
>Whereas I am no
> > > although naive math is, well, naive, more code exists that assumes,
> > > for example, that midnight it time_t % 86400 == 0 than you want to
> > > believe. Changing this is really bad karma.
> >
> > The current situation is that code like your example does not accurately
> > reflect reality.
In message <[EMAIL PROTECTED]>, Greg Hennessy writes:
>My claim is that if POSIX defines time_t % 86400 == 0 as being
>midnight than POSIX doesn't reflect reality, [...]
Well, POSIX clearly doesn't match the scientific definition of
UTC, but as which of the two is more "real" is mostly a matter o
Greg Hennessy scripsit:
> My claim is that if POSIX defines time_t % 86400 == 0 as being
> midnight than POSIX doesn't reflect reality, since people think
> "midnight" as being UTC rather than POSIX.
When it's midnight UTC, a properly time-aware Posix system *will*
report that time_t % 86400 ==
In message: <[EMAIL PROTECTED]>
"Poul-Henning Kamp" <[EMAIL PROTECTED]> writes:
: In message <[EMAIL PROTECTED]>, Greg Hennessy writes:
:
: >My claim is that if POSIX defines time_t % 86400 == 0 as being
: >midnight than POSIX doesn't reflect reality, [...]
:
: Well, POSIX clearly doe
In message <[EMAIL PROTECTED]>, "M. Warner Losh" write
s:
>Either way, it is a pita for the software developer...
... but of course, only if they happen to have heard about it being
their responsibility.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP
> Well, time_t is UTC, which two unfortunate problems.
Is it? I always thought it was a count of the number of seconds since
the start of the unix epoch, not counting leap seconds.
There having been 24 (I think) leap seconds since 1970, the unix
epoch, if POSIX is UTC, then it can't be true that
In message <[EMAIL PROTECTED]>, Greg Hennessy writes:
>> Well, time_t is UTC, which two unfortunate problems.
>
>Is it? I always thought it was a count of the number of seconds since
>the start of the unix epoch, not counting leap seconds.
] Coordinated Universal Time (UTC) includes leap seconds
On Fri 2008-03-28T16:13:01 -0400, Greg Hennessy hath writ:
> Is it? I always thought it was a count of the number of seconds since
> the start of the unix epoch, not counting leap seconds.
>
> There having been 24 (I think) leap seconds since 1970, the unix
> epoch, if POSIX is UTC, then it can't b
In message: <[EMAIL PROTECTED]>
Greg Hennessy <[EMAIL PROTECTED]> writes:
: > Well, time_t is UTC, which two unfortunate problems.
:
: Is it? I always thought it was a count of the number of seconds since
: the start of the unix epoch, not counting leap seconds.
:
: There having been
Working backwards through the messages.
On Mar 28, 2008, at 1:22 PM, M. Warner Losh wrote:
How is that any different than the ITU defining UTC to generally
behave as time has behaved for centuries, except that leap seconds
have a new notation (the :60 stuff)?
ITU didn't create UTC since they
On Mar 28, 2008, at 11:44 AM, Poul-Henning Kamp wrote:
Well, POSIX clearly doesn't match the scientific definition of
UTC, but as which of the two is more "real" is mostly a matter of
philosophy I think.
Both are human constructs. It is mean solar time that is real, that
is, the sidereal da
On Mar 28, 2008, at 10:08 AM, Steve Allen wrote:
It seems unlikely to me that any organization has the standing to
assert an unambiguous time scale that is both operational and
comprehensive across history.
Indeed. This is a function of Mother Earth. Smash a clock offering a
representation
On Mar 28, 2008, at 9:12 AM, Poul-Henning Kamp wrote:
But our problems with POSIX may pale soon, when the politically
ram-rodded, 7000 pages long OOXML standard for "office and business
documents gets ratified by ISO as a "rubberstamp" standard.
As far as I know that standard gets none of leap
On Mar 28, 2008, at 9:04 AM, Poul-Henning Kamp wrote:
Even if we decided to fix time_t's little red wagon for
good, and got the economic resources to do so, we would be very
hard pressed to find the competent man-power to carry it out reliably.
I'm fascinated by your choice of this line of arg
On Mar 28, 2008, at 9:04 AM, Steve Allen wrote:
But if we call POSIX time_t by a new name (say TI) which has
international status and properties which match the specified
characteristics of time_t then what we have is enlightenment.
How about calling it GPS?
The assertion is that TAI itself i
On Fri 2008-03-28T15:36:03 -0700, Rob Seaman hath writ:
> >Provided we get 10 years notice of leapseconds, that timescale
> >can contain leap seconds. If we don't get at least 10 years notice,
> >it should not suffer from them.
>
> We would all be happy with all the notice we could get.
>
> This i
In message <[EMAIL PROTECTED]>, Rob Seaman writes:
>On Mar 28, 2008, at 9:12 AM, Poul-Henning Kamp wrote:
>
>> But our problems with POSIX may pale soon, when the politically
>> ram-rodded, 7000 pages long OOXML standard for "office and business
>> documents gets ratified by ISO as a "rubberstamp"
On Mar 28, 2008, at 4:42 AM, Poul-Henning Kamp wrote:
This is exactly the flagday that will make the upgrades to a few
hundered telescopes look like peanuts.
In grad school one of my housemates was a Swedish postdoc with an
inordinate fondness for Jack Lord and Hawaii Five-O (http://www.you
In message <[EMAIL PROTECTED]>, Rob Seaman writes:
>However complex the current worldwide system of systems comprising our
>civilization, it will only get more complex.
There are actually a significant undercurrent that indicates that this
will not be the case.
Most recent technology, while r
In message <[EMAIL PROTECTED]>, Rob Seaman writes:
>On Mar 28, 2008, at 9:04 AM, Steve Allen wrote:
>
>> But if we call POSIX time_t by a new name (say TI) which has
>> international status and properties which match the specified
>> characteristics of time_t then what we have is enlightenment.
>
>
In message <[EMAIL PROTECTED]>, Rob Seaman writes:
>Per had an entertaining description of the flagday when Sweden
>switched to right-side driving in 1967.
You know the danish version of that story ?
They were afraid that it would be total mayhem to do it in one go,
so the phased it in: First
On Mar 28, 2008, at 4:12 PM, Poul-Henning Kamp wrote:
The thing that seems to be widely overlooked by technologists,
possibly by the high-IQ crowd in general, is that Moores law does
not apply to wetware, and consequently, there very much is a fixed
upper limit for how much technology you can pu
On Mar 28, 2008, at 4:14 PM, Poul-Henning Kamp wrote:
Only if you can convince ISO9000 consultants that there is a
traceability
from this timescale (as distributed by NTP ?) to UTC which forms the
basis of legal timekeeping.
Ahoy! A requirement has been discovered!
On Fri, 28 Mar 2008, Steve Allen wrote:
>
> Part of the beauty of distinguishing broadcast time signals from UTC,
> while continuing both, is that it allows separate issues to be
> addressed separately.
>
> I allow that the broadcast time signals should be leap free, for there
> are many operationa
Tony Finch said:
> So you think that the millions of existing radio controlled clocks and
> watches should stop showing civil time?
They already do.
> Tony (wondering why his MSF clock failed to switch to BST).
Mine changed fine, though it was a bit moot since the entire family was in
Italy unti
On Mon 2008-03-31T12:20:06 +0100, Tony Finch hath writ:
> So you think that the millions of existing radio controlled clocks and
> watches should stop showing civil time?
Yes, that is, yes to a subsecond precision.
They would be showing TI instead of UT, another international
standard, and a diff
Clive D.W. Feather wrote:
Tony Finch said:
So you think that the millions of existing radio controlled clocks
and watches should stop showing civil time?
They already do.
Case in point: When the local Red Cross center relocated a couple of
years ago, new RC "atomic" clocks appeared over
- Original Message -
From: "Rob Seaman" <[EMAIL PROTECTED]>
To: "Leap Second Discussion List"
Sent: Monday, March 31, 2008 10:43 AM
Subject: Re: [LEAPSECS] operational time -- What's in a name?
Clive D.W. Feather wrote:
Tony Finch said:
So you thin
Brian Garrett wrote:
It surprises me that the Red Cross needs this kind of accuracy to
begin with.
They don't, of course. What they do have is a requirement for
reasonably good relative interval timing and absolute timestamps. As
with any COTS solution, the biggest problems may be with
Rob Seaman said:
> Ease of setting is a great feature. But setting a clock
> also involves checking that you set it correctly (selected the right
> combination of buttons on the back).
Um, what buttons on the back? My kitchen RC clock has none such (probably
because just about all of the UK i
Clive D.W. Feather wrote:
Um, what buttons on the back? My kitchen RC clock has none such
(probably because just about all of the UK is in the same time zone).
Right. A typical such clock in the U.S. will have one set of radio
buttons for Eastern/Central/Mountain/Pacific timezones and a se
On Mon, 31 Mar 2008, Rob Seaman wrote:
>
> Like I said, the clocks remained synced through several visits suggesting that
> they received a signal on a regular schedule. They do turn the lights off at
> night, I presume. The underlying clocks are undoubtedly crap, but likely
> can't drift very fa
On Mon, 31 Mar 2008, Clive D.W. Feather wrote:
>
> Um, what buttons on the back? My kitchen RC clock has none such (probably
> because just about all of the UK is in the same time zone).
Mine has buttons to request a radio sync and for manual setting.
http://www.precisionclocks.co.uk/Instructions%
In message <[EMAIL PROTECTED]>, Tony
Finch writes:
>It seems that the reason my MSF clock didn't switch to DST was its
>position - moving it allowed it to resync correctly.
This is one of my major issues with radio-sync clocks: they seldom
tell you they have no idea what time it really is.
--
47 matches
Mail list logo
