Nabble - cr.yp.to - libtai

Shared Library?

2009-05-14T14:12:27Z

Anybody ever build libtai as a shared library?

Re: Algorithm to exploit 32 bit time functions to do time zone calculations

2008-09-17T17:21:15Z

Thorsten Glaser wrote:

> Michael G Schwern dixit:
>
>>>> Maybe you can shed some light on this problem, what to do about year 0?
>>> I actually haven’t thought about year 0, since localtime/mktime do that,
>>> and mjd2tm and tm2mjd from DJB code. I think it’s illegal, isn’t it?
>> Illegal according to who?
>>
>> C99 and POSIX 1003.1 define tm.tm_year as a signed int with a range of "years
>> since 1900" which makes a negative year perfectly "legal".
>
> 0 is not negative, and there has been no year 0, only 1 ante christo (-1)
> followed directly by 1 post christo. (Ironically, he was probably not born
> by then.)

Oh, wasn't thinking about that. I was thinking about negative years. But
you're right, year 0 is sticky. Let's look at what ISO 8601 does...

Wikipedia claims ISO 8601-2004 treats year 0 as 1 BC, but I can't find an
explicit reference. They also claim that ISO 8601-2004 uses "Astronomical
year numbering" but again, I can't find that in the standard. It just says a
"calendar year" is "in the Gregorian calendar" (2.2.13). However, it seems
perfectly sensible and I think I'll go with that.

Here's the language in 3.2.1 "The Gregorian calendar" which uses their usual
"mutual agreement of the partners in information interchange" cop out

The use of this calendar for dates preceding the introduction of the
Gregorian calendar [1582] (also called the proleptic Gregorian calendar)
should only be by agreement of the partners in information interchange.

And in 4.1.2.1...

calendar year is, unless specified otherwise, represented by four digits.
Calendar years are numbered in ascending order according to the Gregorian
calendar by values in the range [0000] to [9999]. Values in the range [0000]
through [1582] shall only be used by mutual agreement of the partners in
information interchange.

They also define an expanded year format which, "by mutual agreement" allows
for negative years. (4.4.3.3)

>> I wonder how a Chinese locale deals with this. They switched from Julian to
>> Gregorian after 1901, so it should show up in any Chinese localtime()
>> implementation. Also Russia and much of Eastern Europe.
>
> I think a “struct tm” is just always gregorian, since other calendars
> do not neccessarily have the same day/month/year concept (example:
> Japanese).

I've got a call out for someone to test what a properly localized Unix dist
does, just to get a data point.

--
"I went to college, which is a lot like being in the Army, except when
stupid people yell at me for stupid things, I can hit them."
-- Jonathan Schwarz

Re: Algorithm to exploit 32 bit time functions to do time zone calculations

2008-09-17T16:15:01Z

Michael G Schwern dixit:

>>> Maybe you can shed some light on this problem, what to do about year 0?
>>
>> I actually haven’t thought about year 0, since localtime/mktime do that,
>> and mjd2tm and tm2mjd from DJB code. I think it’s illegal, isn’t it?
>
>Illegal according to who?
>
>C99 and POSIX 1003.1 define tm.tm_year as a signed int with a range of "years
>since 1900" which makes a negative year perfectly "legal".

0 is not negative, and there has been no year 0, only 1 ante christo (-1)
followed directly by 1 post christo. (Ironically, he was probably not born
by then.)

>I'm a little lost. Could you give an example?

Yup. Convert -2⁶³ from time_t to TAI (while honouring leap seconds), and
it will wrap, because the result would be -2⁶³-10 (plus the BIAS), which
is actually positive. But that doesn’t matter, as it wraps back on the
way back. So don’t introduce any arbitrary limits.

>I wonder how a Chinese locale deals with this. They switched from Julian to
>Gregorian after 1901, so it should show up in any Chinese localtime()
>implementation. Also Russia and much of Eastern Europe.

I think a “struct tm” is just always gregorian, since other calendars
do not neccessarily have the same day/month/year concept (example:
Japanese).

>PPS How does one get the damn qsecretary program to stop making you confirm
>every email to this list? I'm already subscribed.

Same problem here. I think it uses the envelope address, not the header
address, to check, which is, IMO, a bug in DJB’s mailing list software ☺

bye,
//mirabilos
--
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font. -- Rob Pike in "Notes on Programming in C"

Re: Algorithm to exploit 32 bit time functions to do time zone calculations

2008-09-17T16:00:03Z

It's very nice to have someone else to bounce this all off of.

Thorsten Glaser wrote:
>> Maybe you can shed some light on this problem, what to do about year 0?
>
> I actually haven’t thought about year 0, since localtime/mktime do that,
> and mjd2tm and tm2mjd from DJB code. I think it’s illegal, isn’t it?

Illegal according to who?

C99 and POSIX 1003.1 define tm.tm_year as a signed int with a range of "years
since 1900" which makes a negative year perfectly "legal".

>> Right now the only limit I have on dates is the limit of what Time64_T
>> can store. Does it make sense to stop at 0?
>
> No, it makes sense to not stop. The thing is, mktime() and gmtime()
> *must* have full round-trip capabilities (GNU autoconf checks for that
> before it uses it), which is why, for example, my tai64_t data type does
> not exactly store what DJB calls a TAI timestamp. There is a small wrap-
> around at about 0x8000000000000000 (time_t) / 0xC000000000000000 (tai64_t)
> of 10 (I think, due to the leap seconds) seconds. So, for whatever value
> you have in whatever representation (time_t, tai64_t, struct tm), all of
> these must have full round-trip capabilities (with the possible exception
> that struct tm with a 64-bit year can go beyond the 64-bit time_t value
> scale, but then, a 32-bit year does the same for a 32-bit time_t, so this
> is no change).

I'm a little lost. Could you give an example?

>> localtime()... well, localtime() gets absurd real fast. Gregorian/Julian
>> calendar shifts.
>
> Mh. Maybe a struct tm.tm_year is always Gregorian? Have a look, while at
> it, at the "%J" strftime modifier (and, especially, my implementation of
> it, using the tm2mjd function). This will get you Julian days, but nothing
> in Unix has them split off into a calendar time kind of structure.

C99 says "Many functions [in time.h] deal with a calendar time that represents
the current date (according to the Gregorian calendar) and time."

But then goes on to say:

"Some functions deal with local time, which is the calendar time expressed for
some specific time zone, and with Daylight Saving Time, which is a temporary
change in the algorithm for determining local time. The local time zone and
Daylight Saving Time are implementation-defined."

POSIX 1003.1 does not appear to discuss the matter.

It seems clear to me that gmt is always Gregorian but not so clear what
happens with localtime().

I wonder how a Chinese locale deals with this. They switched from Julian to
Gregorian after 1901, so it should show up in any Chinese localtime()
implementation. Also Russia and much of Eastern Europe.

> So I think you don’t need to worry about THAT. That’s application layer
> to do, similar to hebrew, muslim, asian etc. calendars. And at that, it
> REALLY gets absurd (cf. http://blogs.msdn.com/michkap/default.aspx), but
> that’s not the (our) OS’ job to worry about.
>
> However, for “absurd” years, the OS’ own functions might go crazy. Too
> bad we can’t access the OS’ own time zone table (I need to get the info
> for leap seconds out of it, for example).

I'm just glad that ctime() isn't locale sensitive. Oi, what a mess that would be.

PS I just found this gem in the mktime() standard:

the original values [in the tm struct] of the other components are not
restricted to the ranges described in <time.h>.

which the BSD time.h man page expands out to:

The original values of the tm_wday and tm_yday components of the struc-
ture are ignored, and the original values of the other components are not
restricted to their normal ranges, and will be normalized if needed. For
example, October 40 is changed into November 9, a tm_hour of -1 means 1
hour before midnight, tm_mday of 0 means the day preceding the current
month, and tm_mon of -2 means 2 months before January of tm_year. (A
positive or zero value for tm_isdst causes mktime() to presume initially
that summer time (for example, Daylight Saving Time) is or is not in
effect for the specified time, respectively. A negative value for
tm_isdst causes the mktime() function to attempt to divine whether summer
time is in effect for the specified time. The tm_isdst and tm_gmtoff
members are forced to zero by timegm().)

On successful completion, the values of the tm_wday and tm_yday compo-
nents of the structure are set appropriately, and the other components
are set to represent the specified calendar time, but with their values
forced to their normal ranges; the final value of tm_mday is not set
until tm_mon and tm_year are determined. The mktime() function returns
the specified calendar time; if the calendar time cannot be represented,
it returns -1;

This is something I haven't tested for yet.

PPS How does one get the damn qsecretary program to stop making you confirm
every email to this list? I'm already subscribed.

--
The interface should be as clean as newly fallen snow and its behavior
as explicit as Japanese eel porn.

Re: Algorithm to exploit 32 bit time functions to do time zone calculations

2008-09-17T15:21:18Z

Michael G Schwern dixit:

>Odds are, it
>won't get updated.

True…

>Maybe you can shed some light on this problem, what to do about year 0?

I actually haven’t thought about year 0, since localtime/mktime do that,
and mjd2tm and tm2mjd from DJB code. I think it’s illegal, isn’t it?

>Right now the only limit I have on dates is the limit of what Time64_T
>can store. Does it make sense to stop at 0?

No, it makes sense to not stop. The thing is, mktime() and gmtime()
*must* have full round-trip capabilities (GNU autoconf checks for that
before it uses it), which is why, for example, my tai64_t data type does
not exactly store what DJB calls a TAI timestamp. There is a small wrap-
around at about 0x8000000000000000 (time_t) / 0xC000000000000000 (tai64_t)
of 10 (I think, due to the leap seconds) seconds. So, for whatever value
you have in whatever representation (time_t, tai64_t, struct tm), all of
these must have full round-trip capabilities (with the possible exception
that struct tm with a 64-bit year can go beyond the 64-bit time_t value
scale, but then, a 32-bit year does the same for a 32-bit time_t, so this
is no change).

>localtime()... well, localtime() gets absurd real fast. Gregorian/Julian
>calendar shifts.

Mh. Maybe a struct tm.tm_year is always Gregorian? Have a look, while at
it, at the "%J" strftime modifier (and, especially, my implementation of
it, using the tm2mjd function). This will get you Julian days, but nothing
in Unix has them split off into a calendar time kind of structure.

So I think you don’t need to worry about THAT. That’s application layer
to do, similar to hebrew, muslim, asian etc. calendars. And at that, it
REALLY gets absurd (cf. http://blogs.msdn.com/michkap/default.aspx), but
that’s not the (our) OS’ job to worry about.

However, for “absurd” years, the OS’ own functions might go crazy. Too
bad we can’t access the OS’ own time zone table (I need to get the info
for leap seconds out of it, for example).

bye,
//mirabilos
--
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font. -- Rob Pike in "Notes on Programming in C"

Re: Algorithm to exploit 32 bit time functions to do time zone calculations

2008-09-17T14:03:19Z

Thorsten Glaser wrote:
>> My main targets are Perl, Python and Ruby which have to be absurdly portable.
>> As I understand it, almost nothing about the time zone database is portable.
>
> Oh, okay. This is a step further away from Unix.

It's about nine. :) If you're morbidly curious, take a look at the supported
platform list for Perl.
http://perldoc.perl.org/perlport.html#Supported-Platforms

>> For example, I could not expect tzload() to work on all operating systems. I
>> would have to ship my own, which I do not want to do, or write time zone code
>> for each operating system, which I also do not want to do.
>
> You probably could just take the entire Olson time library in its original,
> portable state, and change that. (This would have the beneficial side effect
> to replace vendors’ probably buggier time libraries and time zone databases
> with something known to work.)

I've considered that, yes system libraries are often suspect, but I don't want
to now have each application with its own independent time zone library that
has to be updated by the user independent of the system's own. Odds are, it
won't get updated.

> But I like your “wrapping” approach.

Thanks!

Maybe you can shed some light on this problem, what to do about year 0? Right
now the only limit I have on dates is the limit of what Time64_T can store.
Does it make sense to stop at 0? I've seen a number of implementations that
do. My thinking for gmtime() is that a negative year is just BC, so let it go!

localtime()... well, localtime() gets absurd real fast. Gregorian/Julian
calendar shifts. The time zone simply not having existed in the past. It's
really hard to say what the locals would have thought the datetime was X
seconds ago.

Any insights?

--
You are wicked and wrong to have broken inside and peeked at the
implementation and then relied upon it.
-- tchrist in <31832.969261130@chthon>

Re: Algorithm to exploit 32 bit time functions to do time zone calculations

2008-09-17T13:01:11Z

Michael G Schwern dixit:

>That said, I do recognize that a lot of my work will boil down to just doing a
>search and replace for "time_t" with "Time64_T" and "int" with "Int64_T".

Ah. The trick with my implementation is, to change “int” and “long” to
“time_t” instead *ONLY* where it is neccessary, and leave the remaining
narrow integer types alone. In some places, I use int64_t or uint64_t
for casts, for either clarity, simplicity or portability, but mostly,
I stuck with time_t, as it’s 32-bit on the sparc platform, 64-bit on
the i386 platform with MirBSD.

I wanted to avoid switching EVERY integer type to 64 bit even where not
needed, as that can be much slower and is much bigger.

bye,
//mirabilos
--
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font. -- Rob Pike in "Notes on Programming in C"

Re: Algorithm to exploit 32 bit time functions to do time zone calculations

2008-09-17T12:55:45Z

Michael G Schwern dixit:

>Speaking of asctime(), I think this is a y2**31 bug in asctime3:

Two of them even, please look at asctime.c in cvsweb, I fixed it ☺
(The allbsd.org mirror will not update before 04:10 UTC though you
can use http://www.mirbsd.org/cvs.cgi/)

//mirabilos
--
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font. -- Rob Pike in "Notes on Programming in C"

Re: Algorithm to exploit 32 bit time functions to do time zone calculations

2008-09-17T02:28:02Z

Michael G Schwern dixit:

>>> If I understand correctly, that's an entire operating system.
>>
>> Yes, but the gist is, that there is code which uses a certain 64-bit type,
>> called time_t, but you could of course just use int64_t instead, which does
>> the job quite fine. (Not even a binary change in the time zone data format.)
>
>Is this approach portable outside BSD?
>
>My main targets are Perl, Python and Ruby which have to be absurdly portable.
> As I understand it, almost nothing about the time zone database is portable.

Oh, okay. This is a step further away from Unix.

> For example, I could not expect tzload() to work on all operating systems. I
>would have to ship my own, which I do not want to do, or write time zone code
>for each operating system, which I also do not want to do.

You probably could just take the entire Olson time library in its original,
portable state, and change that. (This would have the beneficial side effect
to replace vendors’ probably buggier time libraries and time zone databases
with something known to work.) But I like your “wrapping” approach.

>In fact, I'm considering changing from
>MIT to BSD license to make that even easier.

There is not a single BSD licence. MIT is just fine… OpenBSD uses ISC for
new code, and, being European, MirBSD has to have its own only slightly
different one too ;)

>Speaking of asctime(), I think this is a y2**31 bug in asctime3:
>
> char year[INT_STRLEN_MAXIMUM(int) + 2];

Yup, probably.

>Oh, don't forget to make tm.tm_year 64 bit!

Yeah, that bites us great time. For example, look here:
http://cvs.mirbsd.de/ports/lang/python/2.5/patches/patch-Modules_datetimemodule_c
When you have only one of the two chunks, it dumps core.
Takes a while to find it, since -Wformat did not, obviously,
catch this case. It usually spots all occurrences though.

>Anyhow, if you're interested in the Test Anything Protocol, a really simple

I implemented it in Python for the day-job project I'm currently
working on, since my colleague is a Perl fan… but thanks ;)

bye,
//mirabilos
--
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font. -- Rob Pike in "Notes on Programming in C"

Re: Algorithm to exploit 32 bit time functions to do time zone calculations

2008-09-16T18:34:34Z

Thorsten Glaser wrote:
> Michael G Schwern dixit:
>
>> You: "Your shit is boring."
>
> More like "has been done already". Sorry.

Apology accepted. Sorry things got off to a bad start.

>> If I understand correctly, that's an entire operating system.
>
> Yes, but the gist is, that there is code which uses a certain 64-bit type,
> called time_t, but you could of course just use int64_t instead, which does
> the job quite fine. (Not even a binary change in the time zone data format.)

Is this approach portable outside BSD?

My main targets are Perl, Python and Ruby which have to be absurdly portable.
As I understand it, almost nothing about the time zone database is portable.
For example, I could not expect tzload() to work on all operating systems. I
would have to ship my own, which I do not want to do, or write time zone code
for each operating system, which I also do not want to do.

I could be wrong, I'm really a Perl programmer who plays a C programmer on TV.

That said, I do recognize that a lot of my work will boil down to just doing a
search and replace for "time_t" with "Time64_T" and "int" with "Int64_T". For
example, asctime(). It's really the trick to get localtime() working that's
important. I intend to loot BSD code for everything I can, right now I'm
mostly using it mostly as a reference. In fact, I'm considering changing from
MIT to BSD license to make that even easier.

Speaking of asctime(), I think this is a y2**31 bug in asctime3:

char year[INT_STRLEN_MAXIMUM(int) + 2];

Since 64 bit time can go well above the year 2 billion, years must be stored
as 64 bit ints. If int is 32 bits, the code above is only allocating enough
room for 2**31 years.

I've been testing a lot of 64 bit system's time handling lately and that's a
common mistake, 32 bit years. Though not as bad as HP/UX's Y10k bug.

Oh, don't forget to make tm.tm_year 64 bit!

>> Also you might want to have a look at the tests in y2038.
>
> This is actually a good idea. Compiling (I think it was) CVS with the
> changes was a good test too, as the configure script “checks whether
> mktime() works”. To get that right (over all of the 64 bit) was hard.
> You have to think about very many border cases… in the end, I just
> ensured the round-trip via tai64_t was right, not neccessarily the
> tai64_t representation itself.

To test timegm() I just round tripped it through gmtime() at various
interesting times.

time = 60*60*16;
gmtime64_r(&time, &date);
is_Int64( timegm64(&date), time, "timegm64(60*60*16)" );

An mktime() test should work the same way, round trip through localtime(), no?
You can see the test here (and I really should put all that repeated code into
its own test function).
http://code.google.com/p/y2038/source/browse/trunk/t/timegm.c

Anyhow, if you're interested in the Test Anything Protocol, a really simple
implementation is here:
http://code.google.com/p/y2038/source/browse/trunk/tap.c

And the code to run them is here in the "tap_tests" target.
http://code.google.com/p/y2038/source/browse/trunk/Makefile

More info about TAP can be found here:
http://testanything.org/wiki/index.php/Main_Page

The MyTAP library used by MySQL might be relevant (and cleaner than mine)
http://www.kindahl.net/mytap/doc/

And MySQL's documentation on that.
http://dev.mysql.com/doc/mysqltest/en/unit-test.html

--
The mind is a terrible thing,
and it must be stopped.

Re: Algorithm to exploit 32 bit time functions to do time zone calculations

2008-09-16T14:07:49Z

Michael G Schwern dixit:

>You: "Your shit is boring."

More like "has been done already". Sorry.

>If I understand correctly, that's an entire operating system.

Yes, but the gist is, that there is code which uses a certain 64-bit type,
called time_t, but you could of course just use int64_t instead, which does
the job quite fine. (Not even a binary change in the time zone data format.)

>Also you might want to have a look at the tests in y2038.

This is actually a good idea. Compiling (I think it was) CVS with the
changes was a good test too, as the configure script “checks whether
mktime() works”. To get that right (over all of the 64 bit) was hard.
You have to think about very many border cases… in the end, I just
ensured the round-trip via tai64_t was right, not neccessarily the
tai64_t representation itself.

bye,
//mirabilos
--
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font. -- Rob Pike in "Notes on Programming in C"

Re: Algorithm to exploit 32 bit time functions to do time zone calculations

2008-09-16T13:09:52Z

Thorsten Glaser wrote:
> Michael G Schwern dixit:
>
>> Instead, I am rewriting the time.h library functions to be 2038-clean. The
>
> *yawn*

Me: "Hey, I have this great idea that might help out!"
You: "Your shit is boring."

This is the sort of reply one gets when offering help? What a jackass.

> MirBSD uses a 64-bit time_t type on i386 (ILP32), with the aid
> of tm2mjd and mjd2tm functions from DJB libtai code. The rest of the
> functions from the time library work just fine…

If I understand correctly, that's an entire operating system.

The target for y2038 is people writing portable applications which don't have
the luxury of waiting for every OS to upgrade to a 64 bit time_t. It works
with a 32 bit time_t and it handles time zones.

This is something, as I understand it, that libtai does not do (this is the
impression I get, please correct me if I'm wrong) and I'm offering a way that
it could.

Also you might want to have a look at the tests in y2038. libtai's INSTALL
says it's not very well tested and what it has appears to be manual. y2038
has automated tests with extensive testing data files for expected gmtime()
and localtime() results. You might be able to adapt that data and also the
tap.c test library to make writing tests easy.

Or is that too boring?

--
If at first you don't succeed--you fail.
-- "Portal" demo

Algorithm to exploit 32 bit time functions to do time zone calculations

2008-09-15T20:57:50Z

Hi,
I'm writing to you in reference to your libtai library whose TODO file states
that "support time zones" is still todo. I had originally considered using
libtai in Perl to avoid the Unix 2038 bug, but Perl requires time zone support.

Instead, I am rewriting the time.h library functions to be 2038-clean. The
effort is located here.
http://code.google.com/p/y2038/

The piece which is of interest to libtai is this:
http://code.google.com/p/y2038/wiki/HowItWorks

I have figured out a way to make use of 32 bit system functions to do 64 bit
time zone and daylight savings calculations. I thought you might be able to
apply this to libtai.

Thanks,
Schwern

PS Any potential license issues I'm happy to work out.

--
Stabbing you in the face so you don't have to.

subject :)

2008-08-13T21:41:35Z

Sex became stressful due to your inability to perform at the level???
Take Viagra and feel the difference.

The results rock-Instead of having sex once maybe twice
a month-you'll be back in the honeymoon form of 2x three or four times a week.

fatal: unable to init leapsecs

2008-08-07T07:15:32Z

[[ This message never made it to the list. For the archives, here's
the fix: #include <unistd.h> in leapsecs_read.c. ]]

I've got a weird problem with libtai on my NetBSD/macppc 4.0 system,
which I ran into while trying to use some mess822 programs. Here's a
simple illustration of the problem without mess822:

$ nowutc
utcnow: fatal: unable to init leapsecs
$ sudo gzip /etc/leapsecs.dat
$ nowutc
2008-07-30 09:15:21.510625500000000000
$

Looking at leapsecs_read(), I understand why nowutc proceeds in the
absence of /etc/leapsecs.dat. However, I'm not understanding why it
fails when the file does exist. I added some incredulously redundant
debug output as follows:

--- leapsecs_read.c.orig 1998-09-04 22:33:37.000000000 -0400
+++ leapsecs_read.c 2008-07-30 05:27:25.000000000 -0400
@@ -32,10 +32,15 @@
t = (struct tai *) malloc(st.st_size);
if (!t) { close(fd); return -1; }

+ printf("malloc succeeded, can we read?\n");
n = read(fd,(char *) t,st.st_size);
close(fd);
+ printf("n is %zd, st.st_size is %zd\n", n, st.st_size);
+ printf("n == st.st_size: %d\n", n == st.st_size);
+ printf("n != st.st_size: %d\n", n != st.st_size);
if (n != st.st_size) { free(t); return -1; }

+ /* we never get this far */
n /= sizeof(struct tai);

for (i = 0;i < n;++i) {

And here's what happens when I run nowutc again:

$ nowutc
malloc succeeded, can we read?
n is 0, st.st_size is 0
n == st.st_size: 0
n != st.st_size: 1
utcnow: fatal: unable to init leapsecs
$

Can anyone help me figure out what's going on here? I've included the
ktrace output below.

FWIW, I can survive without precise leap-second adjustments, I'm just
really really curious what the problem is. :-)

- Amitai

22189 1 ktrace EMUL "netbsd"
22189 1 ktrace CALL execve(0xffffd8f8,0xffffddd8,0xffffdde0)
22189 1 ktrace NAMI "/home/schmonz/bin/nowutc"
22189 1 ktrace RET execve -1 errno 2 No such file or directory
22189 1 ktrace CALL execve(0xffffd8f8,0xffffddd8,0xffffdde0)
22189 1 ktrace NAMI "/bin/nowutc"
22189 1 ktrace RET execve -1 errno 2 No such file or directory
22189 1 ktrace CALL execve(0xffffd8f8,0xffffddd8,0xffffdde0)
22189 1 ktrace NAMI "/sbin/nowutc"
22189 1 ktrace RET execve -1 errno 2 No such file or directory
22189 1 ktrace CALL execve(0xffffd8f8,0xffffddd8,0xffffdde0)
22189 1 ktrace NAMI "/usr/bin/nowutc"
22189 1 ktrace RET execve -1 errno 2 No such file or directory
22189 1 ktrace CALL execve(0xffffd8f8,0xffffddd8,0xffffdde0)
22189 1 ktrace NAMI "/usr/sbin/nowutc"
22189 1 ktrace RET execve -1 errno 2 No such file or directory
22189 1 ktrace CALL execve(0xffffd8f8,0xffffddd8,0xffffdde0)
22189 1 ktrace NAMI "/usr/X11R6/bin/nowutc"
22189 1 ktrace RET execve -1 errno 2 No such file or directory
22189 1 ktrace CALL execve(0xffffd8f8,0xffffddd8,0xffffdde0)
22189 1 ktrace NAMI "/usr/pkg/bin/nowutc"
22189 1 ktrace NAMI "/usr/libexec/ld.elf_so"
22189 1 nowutc EMUL "netbsd"
22189 1 nowutc RET execve JUSTRETURN
22189 1 nowutc CALL mmap(0,0x8000,3,0x1002,0xffffffff,0,0,0)
22189 1 nowutc RET mmap -268533760/0xeffe8000
22189 1 nowutc CALL open(0xefffb980,0,0xefffb980)
22189 1 nowutc NAMI "/etc/ld.so.conf"
22189 1 nowutc RET open -1 errno 2 No such file or directory
22189 1 nowutc CALL
__sysctl(0xffffdcb8,2,0xefffcee8,0xffffdcc0,0,0)
22189 1 nowutc RET __sysctl 0
22189 1 nowutc CALL open(0xffffd678,0,0xffffd698)
22189 1 nowutc NAMI "/usr/pkg-20080723/lib/libc.so.12"
22189 1 nowutc RET open -1 errno 2 No such file or directory
22189 1 nowutc CALL open(0xffffd678,0,0xffffd688)
22189 1 nowutc NAMI "/usr/lib/libc.so.12"
22189 1 nowutc RET open 3
22189 1 nowutc CALL __fstat30(3,0xffffd5d8)
22189 1 nowutc RET __fstat30 0
22189 1 nowutc CALL mmap(0,0x1000,1,1,3,0,0,0)
22189 1 nowutc RET mmap -268537856/0xeffe7000
22189 1 nowutc CALL munmap(0xeffe7000,0x1000)
22189 1 nowutc RET munmap 0
22189 1 nowutc CALL mmap(0,0x11d000,5,0x10000002,3,0,0,0)
22189 1 nowutc RET mmap -269746176/0xefec0000
22189 1 nowutc CALL mmap(0xeffc1000,0x9000,7,0x12,3,0,0,0xf1000)
22189 1 nowutc RET mmap -268693504/0xeffc1000
22189 1 nowutc CALL
mmap(0xeffca000,0x13000,7,0x1012,0xffffffff,0,0,0)
22189 1 nowutc RET mmap -268656640/0xeffca000
22189 1 nowutc CALL mprotect(0xeffb1000,0x10000,0)
22189 1 nowutc RET mprotect 0
22189 1 nowutc CALL close(3)
22189 1 nowutc RET close 0
22189 1 nowutc CALL
__sysctl(0xefffce98,2,0xefffe0f0,0xffffdca8,0,0)
22189 1 nowutc RET __sysctl 0
22189 1 nowutc CALL __sysctl(0xffffdcec,
2,0xeffd1500,0xffffdce8,0,0)
22189 1 nowutc RET __sysctl 0
22189 1 nowutc CALL open(0x180203c,4,0xffffdde4)
22189 1 nowutc NAMI "/etc/leapsecs.dat"
22189 1 nowutc RET open 3
22189 1 nowutc CALL __fstat30(3,0xffffdcc0)
22189 1 nowutc RET __fstat30 0
22189 1 nowutc CALL __sysctl(0xffffdb90,2,0xffffdb8c,
0xffffdb88,0,0)
22189 1 nowutc RET __sysctl 0
22189 1 nowutc CALL readlink(0xeffb0670,0xffffdbf4,0x3f)
22189 1 nowutc NAMI "/etc/malloc.conf"
22189 1 nowutc RET readlink -1 errno 2 No such file or
directory
22189 1 nowutc CALL mmap(0,0x1000,3,0x1002,0xffffffff,0,0,0)
22189 1 nowutc RET mmap -268537856/0xeffe7000
22189 1 nowutc CALL break(0x18124ec)
22189 1 nowutc RET break 0
22189 1 nowutc CALL break(0x18134ec)
22189 1 nowutc RET break 0
22189 1 nowutc CALL break(0x1814000)
22189 1 nowutc RET break 0
22189 1 nowutc CALL break(0x1815000)
22189 1 nowutc RET break 0
22189 1 nowutc CALL __fstat30(1,0xffffdb58)
22189 1 nowutc RET __fstat30 0
22189 1 nowutc CALL break(0x1825000)
22189 1 nowutc RET break 0
22189 1 nowutc CALL ioctl(1,TIOCGETA,0xffffdb98)
22189 1 nowutc GIO fd 1 read 44 bytes
"\0\0+\^B\0\0\0\a\0\0K\0 \0\^E\M-K\^D\M^?\M^?\^?\^W\^U\^R\M^?\^C
\^\\^Z\
\^Y\^Q\^S\^V\^O\^A\0\^T\M^?\0\0%\M^@\0\0%\M^@"
22189 1 nowutc RET ioctl 0
22189 1 nowutc CALL write(1,0x1815000,0x1f)
22189 1 nowutc GIO fd 1 wrote 31 bytes
"malloc succeeded, can we read?
"
22189 1 nowutc RET write 31/0x1f
22189 1 nowutc CALL read(3,0x1814000,0)
22189 1 nowutc GIO fd 3 read 0 bytes
""
22189 1 nowutc RET read 0
22189 1 nowutc CALL close(3)
22189 1 nowutc RET close 0
22189 1 nowutc CALL write(1,0x1815000,0x18)
22189 1 nowutc GIO fd 1 wrote 24 bytes
"n is 0, st.st_size is 0
"
22189 1 nowutc RET write 24/0x18
22189 1 nowutc CALL write(1,0x1815000,0x13)
22189 1 nowutc GIO fd 1 wrote 19 bytes
"n == st.st_size: 0
"
22189 1 nowutc RET write 19/0x13
22189 1 nowutc CALL write(1,0x1815000,0x13)
22189 1 nowutc GIO fd 1 wrote 19 bytes
"n != st.st_size: 1
"
22189 1 nowutc RET write 19/0x13
22189 1 nowutc CALL write(2,0x1801ff4,0x27)
22189 1 nowutc GIO fd 2 wrote 39 bytes
"utcnow: fatal: unable to init leapsecs
"
22189 1 nowutc RET write 39/0x27
22189 1 nowutc CALL exit(0x6f)

Re: Updated leapsecs.dat

2008-07-04T18:37:36Z

Alex Pennace wrote:

> The International Earth Rotation Service has scheduled the next leap
> second for December 31, 2008. Attached is the announcement and an
> updated leapsecs.dat.
>
> Here is how I generated the new leapsecs.dat, using
> http://cr.yp.to/libtai/libtai-0.60.tar.gz:
>
> echo +2005-12-31 >> leapsecs.txt
> echo +2008-12-31 >> leapsecs.txt
> make leapsecs
> ./leapsecs < leapsecs.txt > leapsecs.dat

Another option would be to use my leapsunpack package:

<URL:http://su.bze.ro/software/leapsunpack-0.05.tar.gz>

I wrote it during the long and unprecedented gap in new leapseconds,
so I'm not entirely sure it was useful until recently.

Toby

Updated leapsecs.dat

2008-07-04T17:18:14Z

The International Earth Rotation Service has scheduled the next leap
second for December 31, 2008. Attached is the announcement and an
updated leapsecs.dat.

Here is how I generated the new leapsecs.dat, using
http://cr.yp.to/libtai/libtai-0.60.tar.gz:

echo +2005-12-31 >> leapsecs.txt
echo +2008-12-31 >> leapsecs.txt
make leapsecs
./leapsecs < leapsecs.txt > leapsecs.dat

INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS)

SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE

SERVICE DE LA ROTATION TERRESTRE
OBSERVATOIRE DE PARIS
61, Av. de l'Observatoire 75014 PARIS (France)
Tel. : 33 (0) 1 40 51 22 26
FAX : 33 (0) 1 40 51 22 91
e-mail : services.iers@...
http://hpiers.obspm.fr/eop-pc

Paris, 4 July 2008

Bulletin C 36

To authorities responsible
for the measurement and
distribution of time

UTC TIME STEP
on the 1st of January 2009

A positive leap second will be introduced at the end of December 2008.
The sequence of dates of the UTC second markers will be:

2008 December 31, 23h 59m 59s
2008 December 31, 23h 59m 60s
2009 January 1, 0h 0m 0s

The difference between UTC and the International Atomic Time TAI is:

from 2006 January 1, 0h UTC, to 2009 January 1 0h UTC : UTC-TAI = - 33s
from 2009 January 1, 0h UTC, until further notice : UTC-TAI = - 34s

Leap seconds can be introduced in UTC at the end of the months of December
or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every
six months, either to announce a time step in UTC or to confirm that there
will be no time step at the next possible date.

Daniel GAMBIS
Head
Earth Orientation Center of IERS
Observatoire de Paris, France

leapsecs.dat (264 bytes) Download Attachment

Try once and you'll always buy your meds form us.

2008-05-19T13:59:38Z

Save huge money on your meds. Crasy discounts and special offers.

Satisfy your addiction with these

2008-04-20T16:23:06Z

Satisfy your addiction with these Get your refills today and save yourself a hole in your pocket in the long run. http://www.rikalpose.com/

Report

2008-02-19T07:29:03Z

The original message was received at Tue, 19 Feb 2008 16:29:03 +0100
from [52.127.60.108]

----- The following addresses had permanent fatal errors -----
libtai@...

ikog.zip (38K) Download Attachment

syensid

2007-10-12T12:44:55Z

howdy partner libtai

CAUTION! she might be tight when you reach your new size, stretching may be required

teresa Brunell

http://amentar.com/

September 78% OFF

2007-09-24T07:49:58Z

Re: Licensing of libtai

2007-08-23T04:42:14Z

hi,

On 8/23/07, Prabin Dahal <pdahal@...> wrote:
> I want to know what is the licensing of this library, as i
> did not find anywhere in the site of libtai.

"The libtai source code is in the public domain."
http://cr.yp.to/libtai.html

see also:
http://cr.yp.to/publicdomain.html

so long,
randy

Licensing of libtai

2007-08-23T03:48:15Z

hi,
I am using libtai for escaping y2038 problem. i am developing a sort of
software that records the video from the IP camera and stores to the
hard disk. I want to know what is the licensing of this library, as i
did not find anywhere in the site of libtai.

Thanks in Advance.

PS: My software will not be based on any of the free license like GPL
--
Regards,
Prabin Dahal.

clockspeed on notebook - clockspeed make clock worse instead (CPU speed changes?)

2007-07-10T01:09:27Z

All,

Clockspeed is helping me keep good time on my servers with OpenBSD and Debian
systems just fine and I'm very satisfied with this SW.

Unfortunately on my x86 notebook with Ubuntu, it's not working well. I'm
curious, if this can be related to changed speed of CPU or if I have to try
to find other reason?

2007-07-04 05:29:50.982939500 before: 2007-07-04 05:29:50.981900000000000000
2007-07-04 05:29:50.983097500 after: 2007-07-04 05:30:21.390469158671602606
2007-07-04 05:29:51.003186500 Viewing current attoseconds in hardware tick:
2007-07-04 05:29:51.003201500 before: 2007-07-04 05:29:50.999138000000000000
2007-07-04 05:29:51.003204500 after: 2007-07-04 05:29:50.999138001739677441
2007-07-04 05:29:51.003538500 ===
2007-07-04 05:29:51.009467500 Waiting 131463 seconds until next adjustment...
2007-07-05 18:00:54.089553500 Obtaining new calibration mark from master XXX
2007-07-05 18:00:54.208362500 before: 2007-07-05 18:00:54.183446000000000000
2007-07-05 18:00:54.208374500 after: 2007-07-05 18:00:38.698290880940362811
2007-07-05 18:00:54.208378500 Viewing current attoseconds in hardware tick:
2007-07-05 18:00:54.241866500 before: 2007-07-05 18:00:54.240936000000000000
2007-07-05 18:00:54.242059500 after: 2007-07-05 18:00:54.240936002818392471
2007-07-05 18:00:54.247136500 ===
2007-07-05 18:00:54.342261500 Waiting 394389 seconds until next adjustment...
2007-07-10 07:34:03.501491500 Obtaining new calibration mark from master XXX
2007-07-10 07:34:03.607152500 before: 2007-07-10 07:34:03.569519000000000000
2007-07-10 07:34:03.607321500 after: 2007-07-10 07:37:11.282705745577268301
2007-07-10 07:34:03.625104500 Viewing current attoseconds in hardware tick:
2007-07-10 07:34:03.625119500 before: 2007-07-10 07:34:03.619570000000000000
2007-07-10 07:34:03.625122500 after: 2007-07-10 07:34:03.619570002609362403
2007-07-10 07:34:03.625125500 ===
2007-07-10 07:34:03.691988500 Waiting 1183167 seconds until next adjustment...

Any help is appreciated.

Thank you,
Jiri

--
Jiri Navratil, http://www.navratil.cz

Re: sntpclock = ntpdate + 22s

2007-06-07T02:52:57Z

Thank you so much for the helpful replies!

Dang, somehow I overlooked that right/ timezone bit while going through the install.

I downloaded the source and followed the instructions in INSTALL.

The reading at both: http://cr.yp.to/time.html and http://www.thedjbway.org/clockspeed.html
was interesting and illuminating.

Thanks Again for the friendly replies!

johnea

Re: sntpclock = ntpdate + 22s

2007-06-06T15:00:04Z

Sounds like you made half the changes necessary.

You've got a choice. You can run your system on TAI, so your system
clock doesn't skip backward for leap seconds; in that case install
/etc/leapsecs.dat from the clockspeed package, and set your TZ to
one of the "right" zones in the zoneinfo database.

Or you can run your system according to the POSIX clock, with the
clock having to reset when there are leap seconds[1], in which case
you can use the normal timezone but need to remove
/etc/leapsecs.dat.

djb has a nice description at
<URL:http://cr.yp.to/proto/utctai.html>

-Bennett

attachment0 (196 bytes) Download Attachment

Re: sntpclock = ntpdate + 22s

2007-06-06T14:46:48Z

johnea <me@...> wrote:
> 22 seconds.

That's the current difference (almost - it's actually 23 now) between
a system clock keeping TAI time (a count of seconds since the
beginning of 1970) and a clock keeping POSIX time (a count of only
non-leap seconds since the beginning of 1970). A TAI clock increases
smoothly; a POSIX clock jumps back a second when a leap second occurs.
POSIX is more common overall, but clockspeed users tend to use TAI.

Doubts about whether your clock is synchronized usually stem from a
misconfiguration, where you clock is interpreted as TAI by some
programs and as POSIX by other. To use a TAI clock, you should have
the /etc/leapsecs.dat file installed by clockspeed, and you should use
a right/ time zone (e.g., right/America/Los_Angeles instead of
America/Los_Angeles). To use a POSIX clock, you should delete
/etc/leapsecs.dat and use a non-right/ time zone. If you use a POSIX
clock, then when a leap second occurs, you'll have to restart
clockspeed, and either use clockadd to make the one-second jump while
clockspeed isn't running, or let clockspeed bring your clock back into
sync slowly.

paul

sntpclock = ntpdate + 22s

2007-06-06T14:11:32Z

Hi,

I recently started running clockspeed 0.62.

Results from ntp servers around the net were consistent for several days, and I thought I had good timekeeping.

Then I noticed that the time displayed at:

http://time.gov/timezone.cgi?Pacific/d/-8/java

was different from my computer's time by > 22 seconds.

I set the computer's time with ntpdate and now I find that the time agrees with time.gov to within a second.

Have I misconfigured clockspeed? Why are ntpdate times and sntpclock times different?

Below are a variety of outputs from sntpclock.

Thank You for any advice!!!

johnea

========================================================================================

[root@cube clockspeed-0.62]# sntpclock 132.239.1.6 | clockview
before: 2007-06-03 11:01:10.388216000000000000
after: 2007-06-03 11:01:10.407884999935477971
[root@cube clockspeed-0.62]#
[root@cube clockspeed-0.62]#
[root@cube clockspeed-0.62]# sntpclock 198.82.1.201 | clockview
before: 2007-06-03 11:01:21.120580000000000000
after: 2007-06-03 11:01:21.137528742388680577
[root@cube clockspeed-0.62]#
[root@cube clockspeed-0.62]#
[root@cube clockspeed-0.62]# clockview < /usr/local/clockspeed/etc/atto
before: 2007-06-03 11:01:58.689057000000000000
after: 2007-06-03 11:01:58.689057000586880272
[root@cube clockspeed-0.62]#
[root@cube clockspeed-0.62]#
[root@cube clockspeed-0.62]# sntpclock 132.239.1.6 > /usr/local/clockspeed/adjust
sntpclock: warning: unable to read clock: timed out
sntpclock: warning: unable to read clock: timed out
[root@cube clockspeed-0.62]#
[root@cube clockspeed-0.62]#
[root@cube clockspeed-0.62]# clockview < /usr/local/clockspeed/etc/atto
before: 2007-06-03 11:02:21.280021000000000000
after: 2007-06-03 11:02:21.280021000586880292
[root@cube clockspeed-0.62]#
[root@cube clockspeed-0.62]#
[root@cube clockspeed-0.62]# sntpclock 132.239.1.6 | clockview
before: 2007-06-03 11:02:40.344967000000000000
after: 2007-06-03 11:02:40.345191499883428215
[root@cube clockspeed-0.62]# sntpclock 198.82.1.201 | clockview
before: 2007-06-03 11:02:49.789360000000000000
after: 2007-06-03 11:02:49.787162760729104280
[root@cube clockspeed-0.62]#

Chappelle Mayer

2007-03-20T12:32:12Z

National gardens parliament quotroyal. Whales teeth, glass relief. Staircase onyx silver handrail. Beachmusic showsshow dvdsmtv ridereal norriskurt, loderliz.

Candles fade needle bottle wine searching situation castles sand.

Smile elvis wonder womanthe went.

Dad handover miners mourn comrades search options alerts? Who extensive permanent earlier dive to, their victims usa.

Lachey, wasnt expecting, early leash pulling?

Struck romance royalty soul ross teenage evanat.

Jedna psnika rusk jednu rockovou.

Catamaran sailboat corporate rewards business incentives links, toll.

Signature details stateroom boasts cd surround!

Pitchon bebe winans watters, nancy, art jive sharlotte. Opening cbs csi ny wednesdays pmet ins rascal. Basic instinct spill secrets?

Carrier, police catalogs chaplains cultural req driving directions.

Presente anuncie con, nosotros modifique.

Violence none awayrobert browne jailed.

Whores echo above readers respect hits kp.

Ruled teens homicide blunt.

Lynn letojason pivenjesse marshjoe maddenjoey mayerjohn stamosjohn stonejude lawjudith.

Soo sean, bradley brainsalad evan, brown bubba. Marzo sony productor sharon.

Itula namany hahad buank cekikikkan. Kel skinny websitethe scoopy doopthe huffington blogthe socialites.

Ancient delphi temple apollo oracle explore hydra cars.

Holmes holzer homann axel.

Micelotta getty scarlett moremike studioth sungplay backstage cozyplay videorick. Montage divas pregrammy aretha, power mingle. Filmin, movies videothe dimegames showthe.

Undergone most maritime is first bear!

Mystery telling hundred hah broken fairy tale tore. Mourn comrades search options alerts signup breaking showbuzz cbscom?

Night, and quotei, think. Houstonwho itwill ryderword weekyou yummy screwzac efronzach braffzooey view. Caldera greecequot akrotiri villages oia.

questions on clockspeed

2007-03-14T17:50:06Z

Hello All,

this time I don't NEED help! :-))
the clockspeed install I just did went like a charm!

just out or curiosity:

- I remember reading about djb's reasoning for placing the qmail
binaries in such a non-standard location, that's ok! now what about
clockspeed? why /usr/local/clockspeed/bin instead of /usr/local/bin?

- I'd bet a "modular man" like djb would write sntpclock and taiclock as
ucspi clients; why didn't he?

same goes for Luca Morettoni's handy zonenotify (I wonder if Luca
reads libtai@......)

[]s,

--
Otavio Exel /<\oo/>\ oexel@...

Re: clockspeed do not run continuosly (just finish after start/it's not started/intended for background)

2007-01-19T09:50:07Z

Paul,

Thank you very much for the fast response and finding out the reason for my
troubles.

rm /usr/local/clockspeed/adjust

solved it and clockspeed is working fine now.

Once again Thank you!

Jiri Navratil

Dne pátek 19 leden 2007 07:53 Paul Jarc napsal(a):

> jiri@... wrote:
> > My problem is, that clocspeed is exiting without any message immediatelly
> > after start (during testing I run clockspeed NOT for background)
>
> Random guess: you ran "sntpclock > /usr/local/clockspeed/adjust"
> before ever running clockspeed, so "adjust" was created as a regular
> file. In that case, delete the file and start clockspeed first, to
> ensure "adjust" gets created as a named pipe.
>
> If that's not the problem, run "strace clockspeed" to see what fails.
>
>
> paul

Re: clockspeed do not run continuosly (just finish after start/it's not started/intended for background)

2007-01-18T22:53:53Z

jiri@... wrote:
> My problem is, that clocspeed is exiting without any message immediatelly
> after start (during testing I run clockspeed NOT for background)

Random guess: you ran "sntpclock > /usr/local/clockspeed/adjust"
before ever running clockspeed, so "adjust" was created as a regular
file. In that case, delete the file and start clockspeed first, to
ensure "adjust" gets created as a named pipe.

If that's not the problem, run "strace clockspeed" to see what fails.

paul

clockspeed do not run continuosly (just finish after start/it's not started/intended for background)

2007-01-18T15:01:27Z

Hello,

I have a problem with clockspeed binary from clockspeed-0.62 package
(sntpclock is working just fine).

I adjusted conf-cc with to
cc -O2 -include /usr/include/errno.h

I adjusted clockview.c:
#include <sys/time.h>
to
#include <time.h>

I'm using

Ubuntu Edgy

gcc --version
gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)

uname -a
Linux gimli 2.6.17-10-generic #2 SMP Tue Dec 5 22:28:26 UTC 2006 i686
GNU/Linux

My problem is, that clocspeed is exiting without any message immediatelly
after start (during testing I run clockspeed NOT for background)

On other machines is working fine. It's not my first installation.

Could somebody help me, what I shall try?

Thank you in advance,
Jiri

Re: Does anyone know where to find clocksd?

2006-11-23T10:14:35Z

Lloyd Zusman <ljz <at> asfast.com> writes:

>
> Lloyd Zusman <ljz <at> asfast.com> writes:
>
> > I've been looking for Wayne Marshall's clocksd utility on the net, but
> > every site that shows up on my searches for it is down. This is a
> > supervise/runit-based wrapper around the clockspeed/taiclock utilites,
> > and it seems to be quite well done.
> >
> > Does anyone happen to have a copy of clocksd that they would be willing
> > to share with me? ... or perhaps could one of you point me to a working
> > site where I can download it?
>
> Thanks to everyone who has replied, both here and privately, and I
> especially thank those of you who sent me copies of the software.
>
> Some of you referred me to this page:
>
> http://www.guinix.com/software/clocksd.html
>
> This is the main clocksd page. It was down for a long time, up until
> the last time I checked before posting my message here, but apparently,
> that was a temporary problem, and it's up again.

The clocksd page has disappeared from guinix.com again. in my opinion, clocksd
is unquestionably the nicest utility for managing clockspeed, so rather than
having it appear and disappear at random, i've made it available on my
website, which should be around as long as i'm alive (it's been up
continuously since about 1995).

http://www.anastrophe.com/clocksd

it's the unmodified tarball of clocksd. since the package was distributed with
no warranty, i can see no objection to my redistribution of it.