On Tue, 6 Feb 2007, Horst H. von Brand wrote: > > Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > > [...] > > > What about this language? > > > > The time of the change is specified by `<time>` as the number of > > seconds since the UNIX epoc (midnight, Jan 1, 1970, UTC) and is > > written in base-10 notation using US-ASCII digits. The committer's > > timezone is specified by `<tz>` as a positive or negative offset > > from UTC. For example EST (which is typically 5 hours behind GMT) > > would be expressed in `<tz>` by ``-0500'' while GMT is ``+0000''. > > That is /not/ a timezone! Maybe an offset from UTC. Btw, one thing that might be a good idea to document very clearly: - in the native git format, the offset from UTC has *nothing* to do with the actual time itself. The time in native git is always in UTC, and the offset from UTC does not change "time" - it's purely there to tell in which timezone the event happened. So 12345678 +0000 and 12345678 -0700 are *exactly*the*same*date*, except event one happened in UTC, and the other happened in UTC-7. - in rfc2822 format, the offset from UTC actually *changes* the date. The date "Oct 12, 2006 20:00:00" will be two _different_ times when you say it is in PST or in UTC. And yes, for all I know we might get this wrong inside git too. It's easy to get confused, because they really do mean different things. For an example of this, do make test-date in git (which parses the argument using the "exact date" and "approxidate" versions respectively, and the exact date parsing will give the internal git representation on the first line in the middle column), and then: ./test-date "1234567890 -0800" ./test-date "1234567890 +0000" and then try ./test-date "Fri Feb 13 15:31:30 2009 PST" ./test-date "Fri Feb 13 15:31:30 2009 UTC" and notice how the first two (numeric) dates that differ in UTC offset will still return the exact same seconds since the epoch: 1234567890 -0800 1234567890 +0000 but the second example (with a rfc2822-like date), will show how the seconds-since-epoch changes, and gives: 1234567890 -0800 1234539090 +0000 respectively for those two dates. Logical? It actually is, but you have to understand how git represents date to see the logic. To git, the "timezone" is really totally irrelevant. It doesn't really affect the "date" at all. At most, it affects how you _print_ the date, and you can tell what timezone the computer was set to when the commit was made. And yes, I would not be at all surprised if we had some bug here where we got it wrong occasionally. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html