This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Test GCC conversion with reposurgeon available


On 2019-12-26 16:30:15 -0500, Eric S. Raymond wrote:
> Vincent Lefevre <vincent+gcc@vinc17.org>:
> > > Here's why you want to get timezones right: there are going to be times
> > > when the order of commits is significant information for a developer's
> > > understanding of what happened.  But without a timezone you only know 
> > > the actual time of a commit to 24-hour resoltion.
> > 
> > I don't understand what you mean. What matters for the order of
> > commits is the global time, and this is what SVN stores. SVN does not
> > store timezone information, i.e. it has no idea of what local time of
> > the user had, but I don't think this is important information.
> 
> UTC time plus a timezone offset set is what git stores.  That's not the
> locus of the problem.
> 
> In Subversion-land there's newver any doubt about the sequence of commits;
> the revision numbers tell you that.  In Git-land you have to go by timestamps,
> and if a timezone entry is wrong it can skew the displayed time.

What matters is that the date is correct. I don't think the timezone
matters (that's why SVN doesn't store timezone information, I assume),
possibly except for the committer himself (?). For instance,

  2019-11-27 02:32:02 +0100

and

  2019-11-27 01:32:02 +0000

correspond to the same date. So, each one (as stored in the repository)
is fine if you want to be able to know the order of commits.

What is displayed then is actually a user-config issue. The conversion
utility can't solve this issue, since after conversion, committers will
be able to use any timezone they like.

> Me, I don't undertstand why version-control systems designed for distributed
> use don't ignore timezones entirely and display all times in UTC - relative
> time is surely more imoortant than the commit time's relationship to solar
> noon wherever the keyboard happened to be. But I don't make these decisions.

I agree, at least being able to display all times in a *fixed* timezone
(chosen by the user), as this could be easier for the user to know when
recent commits occur (by "recent", this can be less than 24 hours ago).

For UTC, you can use:

  TZ=UTC git log --date=iso-local

The date format can be stored in ~/.gitconfig, but unfortunately
not local timezone information.

In this case, the timezones of the commits chosen by the conversion
utility will not matter at all.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]