I didn't find it on Google, but about 30 years ago I read an account of a creature like a giant sand dollar that was dislodged from the deep ocean by an undersea earthquake. I can't verify it until I find a reference, but I recall that the scientist examining it found that it was largely silicon, hydrogen, and sulphur (and decayed rapidly giving off H2S). His theory was that it was silicon based life - and that its chemistry required deep ocean temperature and pressure to remain stable. (Note that there are carbon based ocean creatures able to process silicon to create SiO2 structures.)

Your example illustrates localtime() behavior, *not* time() behavior. If you use a timezone that includes leapseconds, then:

$ export TZ=right/US/Eastern; date -d@1230768022; date -d@1230768023; date -d@1230768024
Wed Dec 31 18:59:59 EST 2008
Wed Dec 31 18:59:60 EST 2008
Wed Dec 31 19:00:00 EST 2008

Ya'll keep talking about localtime/mktime, when *I'm* talking 'bout time().

Yes, but we are not talking about mktime (kernel or libc) or localtime. We are talking about time(). If the intent of Posix is that particular time() values convert to particular localtimes() when using posix timezones, then linux is compliant. If you want the correct time of day, you use the "right" timezones - assuming you want the "correct" time of day to include leapseconds. Some systems apparently keep the correct time of day by slowing the time() clock for leapseconds. Doing this means time() is *not* the number of seconds since the epoch, but a smaller number.

To be posix compatible, you have to remove the leap seconds, creating aliased timestamps where the same value of time() refers to different seconds. By not having all that crap in there, and just counting seconds since the epoch, it is sane, simple, and non posix compatible.

However, it is easy to convert the sane result of time() to a posix result with a leap second table. And if I were delivering a posix compatible system, I would do that conditionally so that posix apps (assuming there are any that actually rely on time()%60 == seconds_in_minute) would work.

It is impossible to go the other direction, since the posix time is ambiguous.

Another interpretation could be that posix actually expects time() to be a simple count of seconds, but that the output of *localtime* should guarantee that time()%60 == seconds_in_minute. This would be a constraint on what timezones are allowed in a posix system. In fact, the more I think about it, I think this is what POSIX people really mean. You must use timezone files that do not handle leapseconds. So by not including leap seconds in the default timezones, linux is posix compatible. Only by using the timezone in the "right" directory do you get leapseconds, and are no longer compatible with posix - but time() still returns the same value. It is just the interpretation by localtime() that changes.

This is what I said at first, and what the linux man page implies.

Civil time is "baroque" but usable - every instant has a name, however complex the naming convention. Posix time is "broke" - it can't name every instant. Sane unix systems use a simple second count, which is both simple and usable, and can be converted to posix time when needed (hopefully never).

Civil time represents positive leap seconds as second 60:

23:59:59
23:59:60
00:00:00
00:00:01

DST is disambiguated by the Timezone name:
November 2, 2008 1:00:01 AM EST is an hour later than November 2, 2008 1:00:01 AM EDT.

You are right about the posix definition. But the posix definition is stupid and useless, because it can't unambiguously represent a timestamp - so it is ignored or reinterpreted by sane unix implementations. You can convert a sane clock (like the traditional second count) to posix time (or even most insane localtime based clocks), but not vice versa. So if anyone actually has to run a posix compatible application that is actually braindead enough to rely on time()%60 == seconds_in_minute, then they can set an environment to convert the output of time().

The linux man page for time() mentions the posix definition, and then says they made a mistake - and they really meant seconds since the epoch.

It doesn't matter how NTP protocol represents time - as long as it can be unambiguously converted to system time (i.e. just about anything except posix time could be used). The leap second flag *is* a little weird, but is just a wrinkle when converting to system time.

I am gratified to see that time() in gnu/linux returns seconds since the epoch. They mention the contradictory requirements of Posix, but opine that it was a technical error, and seconds since the epoch is what they really meant (or should have meant).

Technically, you are right. But that has got to be the stupidest thing I've ever seen (not you - the decision by the POSIX committee). POSIX destroys the simple second count just because some braindead application expects time()%60 to be the offset within a minute, instead of using localtime? Because some bozo thinks he can divide seconds by a constant to get days instead of using localtime() (or properly designed substitute), the POSIX committe "makes it so"?

A posix timestamp isn't even an unambiguous time reference. I can deal with discontinuities (just convert to linear time), but the end result of POSIX is utterly and totally useless (can't be unambiguously converted to linear time). For crying out loud, keeping system time as a well defined MDYHMS would be more usable than posix time - at least you can convert to something more manageable.

IMO, everyone should just ignore POSIX time. A Unix timestamp is a plain second count - regardless of the humped monstrosity decreed by POSIX. This can be easily converted to posix time , UTC, GMT, localtime, or any other desired scheme. Posix time can't. It is a non-starter.

Raw unix time is simply a count of seconds since a defined point in time - and has nothing to do with leap seconds. Leap seconds only come into play when converting to human readable display format (along with timezones and DST). Leap seconds have been handled for some time by the zoneinfo library used by most unix and linux distros. Even Java handles leap seconds with my port of zoneinfo to a Java TimeZone implementation.

The tzdata package included in most Linux distros includes leapsecond data in the "right" directory. You can find out the time including leapseconds by setting your TZ environment variable to "right/...". For instance:

$ TZ="right/US/Eastern" date; TZ="US/Eastern" date
Sun Feb 8 17:52:42 EST 2009
Sun Feb 8 17:53:06 EST 2009

The take home salary is *not* the significant cost of hiring an American worker. You have FICA, Medicare, Unemployment insurance, Workers comp, plus lots more nickle and dime costs. Let me illustrate the end result with an example from a country even worse (in this respect - of course it is a nice place in other ways): Brazil.

Brazil got a socialist government that tried to end worker exploitation by decreeing a litany of benefits for all workers. Mandatory unemployment insurance, health care, maximum weekly hours, minimum wage, you name it. If you land a legal job in Brazil, you are really well taken care of - and you even get some spending money. The problem? Very few companies can afford to hire workers following all the rules. So instead, they offer jobs "under the table". You work for us, while officially unemployed, and we'll slip you money under the table. No benefits. No guarantees. This is what most workers in Brazil end up with. The end result is the opposite of the good intentions.

A friend was a lawyer in Brazil working for a non-profit that sued companies that failed to follow all the employment rules. The catch? His law firm hired *their* workers "under the table" with no benefits - they could not afford official workers as a non-profit.

A colleague of mine provided a "translation" of HP BASIC for april fools one year (35 years ago - HP2000). PRINT became SCRIBBLE, IF became SHOULD, GOTO became LEAP, LET became MAKE

10 I = 0
20 SHOULD I = 10 LEAP 50
30 SCRIBBLE I
35 MAKE I = I + 1
40 LEAP 20

Interestingly, no one had any trouble with their assignments (programs were stored tokenized, so you saw the new keywords in the "editor").

Having spent several weeks living in a commune of about 200 people in Vermont, I can say it works very well on that small scale. It wasn't exactly marxist in that people had specialties (soap maker, clothing, gardening, etc). I didn't stay because there were no plans for a programming specialty (and there weren't any available girls I liked).

Everyone knew the leader. Even guests like me got a personal interview. There is some danger of a Jim Jones scenario, but this group was part of an international accountability structure to watch for that kind of thing.

The "secure computing" preached by MS does not protect against OS bugs, buffer overflows, or any of the myriad local or remote attacks based on software flaws. The only "security" it offers is a way to prevent end users from downloading and installing the software of their choice. I don't mean to minimize the value of this - it is an important base to cover. The "typical" Windows user sees a free screen saver and goes "Ooh! Shiny!" and installs it - thereby joining yet another botnet. When/if Linux reaches Windows marketshare, "typical" Linux users will do the same.

Of course, this turns a Windows/TPM computer into something akin to a game console. I personally don't think there is anything wrong with this - until M$ convinces the government to outlaw real computers because they are "insecure". Or more likely, convinces banks and online merchants to only do business with TPM computers.

well, in a way. The problem is that the drive makers optimized their power saving algorithms for Windows disk access patterns - as you would expect them to since it is 85% of the market. And they didn't provide knobs to twist for other OSes - including new, more efficient versions of Windows.

The irony is that Linux runs afoul of the hard drive power saving tuning because it is too efficient. The gaps between disk accesses are too long, and trigger a head unload while the OS is still active.

The best fix would be to twist a knob to adjust the inactivity timer - but that isn't available. So the simplest fix is to disable power saving on the disk - fine for laptops used as portable desktops. To keep drive power saving without unloading/loading the heads constantly, you have to configure "laptop mode", which uses memory to cache reads/collect writes so as to provide something like 30 minutes between disk accesses for typical word processing/browsing activities.

I've thought about writing a background process (in python or your favorite script language) that monitors iostat - and reads a raw sector every 9 seconds to keep the disk from thinking we are inactive. At the same time, we have our own Linux oriented inactivity timer, and stop reading the raw sectors when the system is truly inactive (other than our own reads).