From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [OT] Re: [PATCH 3/18] allow callers of seq_open do allocation themselves Date: Mon, 7 Nov 2005 19:45:27 -0800 (PST) Message-ID: References: <20051107190340.129bc8c3.rdunlap@xenotime.net> <17264.6769.472245.973213@cse.unsw.edu.au> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "Randy.Dunlap" , Al Viro , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linuxram@us.ibm.com Return-path: To: Neil Brown In-Reply-To: <17264.6769.472245.973213@cse.unsw.edu.au> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 8 Nov 2005, Neil Brown wrote: > On Monday November 7, rdunlap@xenotime.net wrote: > > > > What format is that date in, please? > > %s %z > > (as date(1) understands it). Yes. It happens to be one of the formats git understands, and is also the least ambiguous. > Or was this a rhetorical question, meaning to say "Who in their right > mind would used that sort of date format on a public mailing list?" :-) Yeah, it's really only machine-readable. In this case git-readable, although git will accept dates in almost any format. It happens to be the format internally used by git, since it's easy to parse and you can't get it wrong. It may be a mistake to expose it outside in that format, though. The git "format patch as email" script will just use the internal date format, which is nice from a "you can't get it wrong" angle, but arguably not very human-friendly. Not being able to get it wrong by converting it to a human-readable format and then converting it back is a pretty big advantage, though (it's damn easy to screw up summer-time and timezone when converting to/from UTC: the "%s %z" format doesn't leave any confusion: the seconds is always since the epoch in UTC, and the %z is purely informational to tell in which timezone the change was made). Linus