info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs log and UTC


From: Mark D. Baushke
Subject: Re: cvs log and UTC
Date: Wed, 24 Mar 2004 13:55:27 -0800

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Derek Robert Price <address@hidden> writes:

> Mark D. Baushke wrote:
> 
> > Derek Robert Price <address@hidden> writes:
> >
> > I have a minor quibble, the timezone should be numeric -0000 rather than
> > the alphabetic UTC. However, I agree that a timezone indication in the
> > output of cvs log and friends would be reasonable.
> 
> 
> Um, yes.  If I'd thought about the matter more I probably would have
> suggested the same thing.

In fact, I suggest that movement to ISO 8601 format for output would be
desirable. That is,

    ISO 8601 format "yyyy-dd-mm hh:mm:ss -0000"
vs
    cvs log's format of 'yyyy/mm/dd hh:mm:ss'

a bigger question is if that change should also go into things like $Id$
and other RCS keyword expansion strings...
 
> > I will also state that if a change to the output of 'cvs log' and 'cvs
> > rlog' to add the timezeone is performed, there is likely going to need
> > to be a compatibility switch for the old format to allow the transition
> > to be chosen by the cvs administrators.
> 
> 
> Since the server upgrade would not be sufficient to cause the output
> format to change (in the tagged text case under discussion), and the
> clients would need to be upgraded, would you consider it sufficient that
> they admin could specify a path to the old client in their scripts even
> though they had upgraded their server?  Hrm.  Probably not.  A
> compatibility switch wouldn't be a big deal though I might vote that the
> feature code at least issue a deprecation warning when such a switch was
> used.  Then we can remove the date-compatibility option entirely in the
> next stable release.  :)

I suspect this may depend on how extensive the changes are with regard
to keyword expansion and what the user community feels should happen.

If we are opening the hood on timestamp changes, we probably want to get
a good look at all the places that timestamps are used and make sure we
understand how it relates to this change.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAYgPP3x41pRYZE/gRAo3OAJ9//bfpNF8WDyLJoEx3xZ1fitzRhgCg40m2
Q6Rpm81R2vw92eOYY/g/MjY=
=HZaK
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]