[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Repo cpnversion progress report
From: |
Eric S. Raymond |
Subject: |
Re: Repo cpnversion progress report |
Date: |
Fri, 31 Jan 2014 23:19:27 -0500 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Paul Eggert <address@hidden>:
> Eric S. Raymond wrote:
> >I'm not real happy about the action stamps being so long as it is.
>
> How about a POSIX timestamp rather than an ISO 8601 string?
> "address@hidden", for example, instead of
> "2014-01-31T21:44:address@hidden". Although it's just 9
> characters difference, the savings add up when you're trying to read
> a screenful of these things.
Clever hack! I really, really liked this idea - for about thirty seconds.
Then I remembered, dammit, that I have run into a fair amount of
confusion over whether that kind of Unix time is based on a UTC or
local epoch. That's why the Z in RFC3339 date format is functional; it
pins the stamp to Zulu time.
Yes, I know POSIX time is supposed to be seconds UTC (sort of, modulo
leap seconds). People get confused anyway - in fact I remember a
Linux distribution that actually gave you an installation choice about
whether to keep your integer timestamps in local or in UTC a la POSIX. I
boggled.
If we leave this ambiguous in the representation, someone in the
future will curse us. And not without reason. Because even if they
know the right UTC-based interpretation of Unix time, they have no way
to be sure everyone who touched the data *before* them did.
(Wearing my GPSD maintainer hat I have to deal with crap like this a lot.)
More generally, we'd lose the self-describing property. It's hard to look
at an RFC3339 timestamp and not know what it is. Not so much with an integer
literal.
So yes, a clever hack. But, alas. Not, I fear, a good one.
If we really had to deal with screenfulls of these things the tradeoff
might potentially be different. That actually happened in the change
comments of the NUT project. Not here, though. The worst case I've
seen in the Emacs history is two of them per line, one pair per
commit message or ChangeLog entry.
> As I understand it the first glimmer of Emacs in RMS's eye was circa
> 1972, so even if we magically resurrected his original code the
> timestamps would never need to be negative. We could say that
> time-since-1970 is "Emacs time".
Ha. You know what popped into my head when I read that last? "1970
is as old as the world."
Text Editors in The Lord of the Rings
http://crookedtimber.org/2011/07/30/text-editors-in-the-lord-of-the-rings/
Emacs: Fangorn
Vast, ancient, gnarled and mostly impenetrable, tended by a small band
of shepherds old as the world itself, under the command of their
leader, Neckbeard. They possess unbelievable strength, are
infuriatingly slow, and their land is entirely devoid of women. It
takes forever to say anything in their strange, rumbling language.
When I read that, I do not mind telling you that I felt my age. :-)
I've been thinking about that satire a lot lately.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
- Re: Repo cpnversion progress report, (continued)
- Re: Repo cpnversion progress report, Eli Zaretskii, 2014/01/31
- Re: Repo cpnversion progress report, Sean Sieger, 2014/01/31
- Re: Repo cpnversion progress report, Sean Sieger, 2014/01/31
- Re: Repo cpnversion progress report, Karl Fogel, 2014/01/31
- Re: Repo cpnversion progress report, Eli Zaretskii, 2014/01/31
- Re: Repo cpnversion progress report, Eric S. Raymond, 2014/01/31
- Re: Repo cpnversion progress report, Paul Eggert, 2014/01/31
- Re: Repo cpnversion progress report, Eric S. Raymond, 2014/01/31
- Re: Repo cpnversion progress report, Paul Eggert, 2014/01/31
- Re: Repo cpnversion progress report, Juanma Barranquero, 2014/01/31
- Re: Repo cpnversion progress report,
Eric S. Raymond <=
- Re: Repo cpnversion progress report, Stefan Monnier, 2014/01/31
- Re: Repo cpnversion progress report, Eric S. Raymond, 2014/01/31
- Re: Repo cpnversion progress report, Jan D., 2014/01/31
- Re: Repo cpnversion progress report, Eric S. Raymond, 2014/01/31
- Re: Repo cpnversion progress report, Stefan Monnier, 2014/01/31
- Re: Repo cpnversion progress report, Eric S. Raymond, 2014/01/31