From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Tue,  2 Sep 2014 19:00:56 -0400
To: 9fans@9fans.net
Message-ID: <db849a10446d6804683a53529ac98cf2@ladd.quanstro.net>
In-Reply-To: <20140902215053.Horde.Ajvc1qAreH0gSqu6LYJmDw6@ssl.eumx.net>
References: <346c54679a6cdc9bb557724d8b93bbc6@quintile.net>
	<6e2a7a02201fcf3ea5d0d894d0d16916@ladd.quanstro.net>
	<20140902200400.81EAAB827@mail.bitblocks.com>
	<14dad84410389f1daea3b71e632cb980@ladd.quanstro.net>
	<20140902215053.Horde.Ajvc1qAreH0gSqu6LYJmDw6@ssl.eumx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] silly question
Topicbox-Message-UUID: 150eeb32-ead9-11e9-9d60-3106f5b1d025

> > correct.  plan 9 does not bother with leap seconds.
>
> seconds(1) "handles" leap seconds in that it will not crash
> when it encounters them -- it accepts that sometimes there
> are 61 seconds in a minute.

i'm not sure if we're talking past each other, or making different points.
but either way, i should clarify.

by "not handling leap seconds" i mean there is no code in ctime() to add
in leap seconds from an external source at the appropriate unix times.
so e.g. gmtime could read e.g. /lib/leapseconds and ajust seconds similar
to days (/sys/src/libc/9sys/ctime.c:137,138).

- erik