Re: cvs log and UTC

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Jim.Hyslop wrote:

>Seems to me the best way to implement this would be to have a global option
>which controls the date format, something like:
>
>-l  Display local time for timestamps
>-u  Display UTC for timestamps


Maybe.  I think I would prefer stressing the ISOness of the new dates,
but it's not a big deal.  Maybe something more like:

-i   Display local ISO8601 dates for timestamps.
-o  Display timestamps in CVS's legacy formats & UTC.

>Default for the next stable release would be -u, then eventually it
could be
>changed to -l.


It would default to -i in feature and -o in stable.  -o & -i would be
deprecated in feature and therefore the next stable _series_ of
releases.  Next feature _series_ (and therefore the following stable)
would have -o and -i options removed entirely.

>And, of course, all timestamp displays should go through a single function.


Of course.

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQFAYwCzLD1OTBfyMaQRAiBUAKCyu/Gz6/hPOqK8+eV5H8sRsWPBCQCgkpYr
WPIfXaxwu/7q9rARzmI+Deg=
=rQqi
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: cvs log and UTC

[Jim.Hyslop]

Derek Robert Price wrote:
> Mark D. Baushke wrote:
> > a bigger question is if that change should also go into 
> > things like $Id$
> > and other RCS keyword expansion strings...
> 
> 
> Got me here.  I tend to avoid RCS keywords as much as 
> possible.  I know
> that they are useful via the `ident' command, but that is 
> supposed to be
> human readable, I think.  Even if it is intended to be 
> machine readable,
> I would say standards would be better.  What do other people think?
I agree - consistent date format is good, and using an ISO standard is even
better.

I think the RCS keywords should also be expanded. Now, having said that, I
also have to point out that I'm not aware of all the other utilities that
may depend on the keyword expansion - I'd never have considered the impact
on `ident', for example.

Seems to me the best way to implement this would be to have a global option
which controls the date format, something like:

-l  Display local time for timestamps
-u  Display UTC for timestamps

Default for the next stable release would be -u, then eventually it could be
changed to -l.

And, of course, all timestamp displays should go through a single function.

> Regardless, when we're just talking about rewriting scripts using CVS
> output to parse _more standard_ dates, I personally don't consider the
> change drastic or the effects catastrophic.  In the long run it would
> certainly be a good thing.
Agreed here, as well.


-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Frederic Brehm]

At 04:19 PM 3/24/2004, Derek Robert Price wrote:
At the least, `cvs log' output should be
changed to contain the "UTC" string.
As a side effect, it would help reduce the number of queries about this 
from novice CVS users.

Fred

___
Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark D. Baushke wrote:

> In fact, I suggest that movement to ISO 8601 format for output would be
> desirable. That is,
>
> ISO 8601 format "-mm-dd hh:mm:ss -"
> vs
> cvs log's format of '/mm/dd hh:mm:ss'


[I corrected the ISO 8691 format in the above quote.]

It's only a matter of replacing the slashes (`/') with dashes (`-'), so
that change should be pretty straightforward too.

> a bigger question is if that change should also go into things like $Id$
> and other RCS keyword expansion strings...


Got me here.  I tend to avoid RCS keywords as much as possible.  I know
that they are useful via the `ident' command, but that is supposed to be
human readable, I think.  Even if it is intended to be machine readable,
I would say standards would be better.  What do other people think?


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


Granted, but the compatibility flag could be attached to lots of
commands.  Hrm.  I think that when I wrote stable/feature up somewhere,
I proposed that deprecated features be deprecated for an entire stable
release regardless.  I don't recall where.  My memory just got it
confused this pass.

Regardless, when we're just talking about rewriting scripts using CVS
output to parse _more standard_ dates, I personally don't consider the
change drastic or the effects catastrophic.  In the long run it would
certainly be a good thing.

> 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.


By all means, look.  :)  What I've heard so far sounds pretty good.

Derek
- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQFAYi/fLD1OTBfyMaQRAp69AJ9411wHhWISYsv2nRt9RZzV27yetACgzOff
q+Hm5GY9N/j45CQVxQUgclw=
=DjWd
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Mark D. Baushke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Larry Jones <[EMAIL PROTECTED]> writes:

> Mark D. Baushke writes:
> > 
> > ISO 8601 format "-dd-mm hh:mm:ss -"
> 
> You've got the mm and dd swapped, it's "-mm-dd hh:mm:ss -".

Yes. Mea culpa. I cut-n-pasted a line from src/sanity.sh which happens
to have been wrong. I have committed the fix to src/sanity.sh for this.

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

iD8DBQFAYhZI3x41pRYZE/gRAoFyAJ9XBaJMKPJzjp89ox1ICzLANAF31ACgm2Op
1mW0yfLNMXLlzjFvPVv6GG8=
=1I53
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Mark D. Baushke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul Sander <[EMAIL PROTECTED]> writes:

> There should be little need to parse the output of "cvs log" or "cvs rlog"
> if you have access to the server and can run rinfo on the RCS files. It
> produces output that's designed to be machine readable.  Sources are
> located at:
> 
> http://www.wakawaka.com/source.html

Thank you for the pointer.

I have been aware of rinfo for a number of years, but it is a good thing
to remind folks it exists.

That said, access to the server for such purposes is not always
available. It depends on the nature of the organizations/companies that
maintain the cvs repository and how strictly the repository sources are
kept as to wether having access to the raw ,v files will be possible for
the rinfo command to use.

There are also some CVS concepts with regard to 'magic branches' and the
dead state that are not really accounted for by the rinfo program (or
such is my recollection from a few years ago).

If someone were to provide similar functionality into a patch to provide
something like a 'cvs info' or 'cvs rinfo' command, I suspect that many
folks would find it useful.

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

iD8DBQFAYhr53x41pRYZE/gRAk7OAJ9Y6DCN83fCQ9bHI6FW2dOHjDKmUwCcCfFO
EkDPG+N8MVoApzt8DVPthxc=
=/5wx
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Paul Sander]

>--- Forwarded mail from [EMAIL PROTECTED]

>Derek Robert Price <[EMAIL PROTECTED]> writes:

>> Mark D. Baushke wrote:

>> The `cvs log' output is definately not designed to be machine
>> parsable, as you would likely know if you have ever tried to parse it.

>I have many thounsands of lines of perl, gawk and C spread across
>multiple companies that parse the 'cvs log' and 'cvs rlog' output and I
>understand the problem of trying to machine parse such output very
>clearly.

There should be little need to parse the output of "cvs log" or "cvs rlog"
if you have access to the server and can run rinfo on the RCS files.  It
produces output that's designed to be machine readable.  Sources are
located at:

http://www.wakawaka.com/source.html

>--- End of forwarded message from [EMAIL PROTECTED]



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: cvs log and UTC

[Donald Sharp \(sharpd\)]

Yes, please, I can't tell you the hell I've had recently with Timezones
being non-numeric.

Did you know that Australia has a EST timezone that nicely corresponds
to the East coast of the united states?

donald

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Derek
Robert Price
Sent: Wednesday, March 24, 2004 4:46 PM
To: Mark D. Baushke
Cc: Liza Blaney; [EMAIL PROTECTED]
Subject: Re: cvs log and UTC


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark D. Baushke wrote:

> Derek Robert Price <[EMAIL PROTECTED]> writes:
>
> I have a minor quibble, the timezone should be numeric - 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.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Larry Jones]

Mark D. Baushke writes:
> 
> ISO 8601 format "-dd-mm hh:mm:ss -"

You've got the mm and dd swapped, it's "-mm-dd hh:mm:ss -".

-Larry Jones

The hardest part for us avant-garde post-modern artists is
deciding whether or not to embrace commercialism.  -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Mark D. Baushke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Derek Robert Price <[EMAIL PROTECTED]> writes:

> Mark D. Baushke wrote:
> 
> > Derek Robert Price <[EMAIL PROTECTED]> writes:
> >
> > I have a minor quibble, the timezone should be numeric - 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 "-dd-mm hh:mm:ss -"
vs
cvs log's format of '/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-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark D. Baushke wrote:

> Derek Robert Price <[EMAIL PROTECTED]> writes:
>
> I have a minor quibble, the timezone should be numeric - 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.

> >The `cvs log' output is definately not designed to be machine
> >parsable, as you would likely know if you have ever tried to parse it.
>
> I have many thounsands of lines of perl, gawk and C spread across
> multiple companies that parse the 'cvs log' and 'cvs rlog' output and I
> understand the problem of trying to machine parse such output very
> clearly.


Excuse me - I should have said, "as you _will_ likely know"...  :)

> 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.  :)

Derek
- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQFAYgGKLD1OTBfyMaQRAk06AKDl+yB9jChmrhqs/d0qL3OTyj6I2ACfbptg
dzlK0xw8+or+y/D9rdZzQa4=
=P3nl
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Mark D. Baushke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Derek Robert Price <[EMAIL PROTECTED]> writes:

> Mark D. Baushke wrote:
> 
> > Blaney, Liza <[EMAIL PROTECTED]> writes:
> >
> > >I have been asked to "fix" this by my boss:
> >
> > Summary: It is not a bug and does not need to be fixed.
> > (See also the advice for engineers to a PHB via the Dilbert.com site.)
> 
> 
> This is debatable.

So it seems. :-)

> > >cvs log returns the timestamp of the file in Coordinated Univeral
> > >Time.
> >
> > This is correct.
> >
> > >All other ways of looking at the timestamp return it in local time.
> >
> > I believe you to be mistaken. Could you please cite examples? I do not
> > believe that cvs will ever OUTPUT time in localtime. If it does, it is
> > probably a bug.
> >
> > Had you said that by default you are able to ENTER a timestamp for
> > checkout (the -D switch) in localtime, then I would have to agree with
> > you. Data entry will also accept '2004/03/22 21:11:06 UTC' as a
> > datestamp and mean UTC instead of localtime.
> 
> 
> This is what I definately consider a bug, or at least a serious
> usability issue: when the time string output by `cvs log' is copied and
> pasted into the argument for -D from any other command, it is
> interpreted as localtime.  At the least, `cvs log' output should be
> changed to contain the "UTC" string.

I have a minor quibble, the timezone should be numeric - rather than
the alphabetic UTC. However, I agree that a timezone indication in the
output of cvs log and friends would be reasonable.

> > >Is there any quick, elegant way to get cvs log to display the date in
> > >local time? (I think I know the answer.) Thanks.
> >
> > 
> > Sure thing...
> >
> > Have your boss add the following line to his .profile
> >
> >  TZ=GMT; export TZ
> >
> > or the following line to his .cshrc
> >
> >  setenv TZ GMT
> >
> > and he will find that the output of cvs log will have dates very similar
> > to the 'date' command he issues. Of course, this may not work in a
> > Windows environment, but I am sure you get the idea.
> >
> > Or, you can teach your boss the 'date -u' command.
> > 
> 
> 
> Mark, I think you just proved a point in favor of changing the log time
> output to localtime.  This is that most commands with output intended to
> be read by humands will output time dependent on the value of TZ, and
> CVS should follow this lead when its output is intended primarily to be
> read by humans.

I won't deny it.

> I would argue that annotate fits this category (and rlog, of course),
> but diff and rdiff, by virtue of their output beign mainly designed to
> be machine parsable and their format being defined elsewhere, should
> not honor TZ.

The output of 'cvs diff' at least specifies the timezeone - already.

> The `cvs log' output is definately not designed to be machine
> parsable, as you would likely know if you have ever tried to parse it.

I have many thounsands of lines of perl, gawk and C spread across
multiple companies that parse the 'cvs log' and 'cvs rlog' output and I
understand the problem of trying to machine parse such output very
clearly.

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.

> > In all seriousness, you should ask your boss if he really wants to
> > confuse folks who need to use your cvs repository about what time
> > a change was made by having it appear differently depending on the
> > machine in the network they happened to be logged into at the time.
> >
> > I regularly login to machines in UTC-0800 UTC-0500 and UTC+0530 and it
> > is even more exciting when some of those machines automagically switch
> > to UTC-0700 UTC-0400 during daylight savings time. I expect the output
> > to be the same regardless of the window in which I happen to type a
> > 'cvs log' command. The only way to deal with world-wide development
> > teams is to have a single time standard used for the important stuff
> > and UTC is just the standard to use for cvs.
> 
> 
> And you should set your TZ environment variable to "GMT" or "UTC" on all
> these systems after this bug is fixed if that is what you really want to
> see.

I've done it before... :-)

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

iD8DBQFAYf9r3x41pRYZE/gRAn97AKDhnp/x8Q/87zVeZYkZsD1CokwxlACfVIik
HV+i7aDtPsFIgeSRuCboO2c=
=P0bJ
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Doar wrote:

>If your boss wants to see local timestamps on cvs output, that's much
>more work, as others have pointed out.


I still say there are only two minor edits that would need to be made to
the CVS source.  Three if you want to include the `annotate' output.
Not that I have the time just now, I must admit.

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQFAYf5MLD1OTBfyMaQRAuo6AJ9ubdEuD0tzRMLOaVtPY5TJf/k3NQCg5LDJ
D2o2GRP60BN/eDQo1P0Dkyg=
=lZ5C
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Derek Robert Price wrote:

> Matthew Doar wrote:
>
> >If your boss wants to see local timestamps on cvs output, that's much
> >more work, as others have pointed out.
>
> I still say there are only two minor edits that would need to be made to
> the CVS source.  Three if you want to include the `annotate' output.
> Not that I have the time just now, I must admit.


The time, that is, to do anything more than review and apply a patch.

Derek
- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQFAYf6MLD1OTBfyMaQRAqlTAKD9ZcX+AJEbOLWN4k9qo8VMHqbN0gCdFZ4t
jLADdXPpyl3PJbap/GVfoIw=
=q0WN
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark D. Baushke wrote:

> Blaney, Liza <[EMAIL PROTECTED]> writes:
>
> >I have been asked to "fix" this by my boss:
>
> Summary: It is not a bug and does not need to be fixed.
> (See also the advice for engineers to a PHB via the Dilbert.com site.)


This is debatable.

> >cvs log returns the timestamp of the file in Coordinated Univeral
> >Time.
>
> This is correct.
>
> >All other ways of looking at the timestamp return it in local time.
>
> I believe you to be mistaken. Could you please cite examples? I do not
> believe that cvs will ever OUTPUT time in localtime. If it does, it is
> probably a bug.
>
> Had you said that by default you are able to ENTER a timestamp for
> checkout (the -D switch) in localtime, then I would have to agree with
> you. Data entry will also accept '2004/03/22 21:11:06 UTC' as a
> datestamp and mean UTC instead of localtime.


This is what I definately consider a bug, or at least a serious
usability issue: when the time string output by `cvs log' is copied and
pasted into the argument for -D from any other command, it is
interpreted as localtime.  At the least, `cvs log' output should be
changed to contain the "UTC" string.

> I believe you will find that 'cvs log', 'cvs rlog', 'cvs diff',
> 'cvs rdiff', 'cvs annotate', 'cvs rannotate' are all using times and
> dates generated from the UTC representation of the change.


Yep.

> >Is there any quick, elegant way to get cvs log to display the date in
> >local time? (I think I know the answer.) Thanks.
>
> 
> Sure thing...
>
> Have your boss add the following line to his .profile
>
>  TZ=GMT; export TZ
>
> or the following line to his .cshrc
>
>  setenv TZ GMT
>
> and he will find that the output of cvs log will have dates very similar
> to the 'date' command he issues. Of course, this may not work in a
> Windows environment, but I am sure you get the idea.
>
> Or, you can teach your boss the 'date -u' command.
> 


Mark, I think you just proved a point in favor of changing the log time
output to localtime.  This is that most commands with output intended to
be read by humands will output time dependent on the value of TZ, and
CVS should follow this lead when its output is intended primarily to be
read by humans.  I would argue that annotate fits this category (and
rlog, of course), but diff and rdiff, by virtue of their output beign
mainly designed to be machine parsable and their format being defined
elsewhere, should not honor TZ.  The `cvs log' output is definately not
designed to be machine parsable, as you would likely know if you have
ever tried to parse it.

> In all seriousness, you should ask your boss if he really wants to
> confuse folks who need to use your cvs repository about what time
> a change was made by having it appear differently depending on the
> machine in the network they happened to be logged into at the time.
>
> I regularly login to machines in UTC-0800 UTC-0500 and UTC+0530 and it
> is even more exciting when some of those machines automagically switch
> to UTC-0700 UTC-0400 during daylight savings time. I expect the output
> to be the same regardless of the window in which I happen to type a
> 'cvs log' command. The only way to deal with world-wide development
> teams is to have a single time standard used for the important stuff
> and UTC is just the standard to use for cvs.


And you should set your TZ environment variable to "GMT" or "UTC" on all
these systems after this bug is fixed if that is what you really want to
see.

Derek
- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQFAYftuLD1OTBfyMaQRAjWyAJ4/GZyKrtIrZkCy/MVPmqBENc+8kACgvpf7
Gjhsu59iDFNqVqi/2j0ENLU=
=HBb9
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Matthew Doar]

I use change logs generated by cvs2cl.pl http://www.red-bean.com/cvs2cl
and the XSLT transformation from
http://www-106.ibm.com/developerworks/library/us-gentoo4, all of which
produces very useful HTML, with the advantage that I can set the time
zone to whatever I want for different HTML reports.

If your boss wants to see local timestamps on cvs output, that's much
more work, as others have pointed out.

~Matt


signature.asc
Description: This is a digitally signed message part
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Mark D. Baushke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Blaney, Liza <[EMAIL PROTECTED]> writes:

> I have been asked to "fix" this by my boss: 

Summary: It is not a bug and does not need to be fixed.
(See also the advice for engineers to a PHB via the Dilbert.com site.)

> cvs log returns the timestamp of the file in Coordinated Univeral
> Time.

This is correct.

> All other ways of looking at the timestamp return it in local time.

I believe you to be mistaken. Could you please cite examples? I do not
believe that cvs will ever OUTPUT time in localtime. If it does, it is
probably a bug.

Had you said that by default you are able to ENTER a timestamp for
checkout (the -D switch) in localtime, then I would have to agree with
you. Data entry will also accept '2004/03/22 21:11:06 UTC' as a
datestamp and mean UTC instead of localtime.

I believe you will find that 'cvs log', 'cvs rlog', 'cvs diff',
'cvs rdiff', 'cvs annotate', 'cvs rannotate' are all using times and
dates generated from the UTC representation of the change.

> Is there any quick, elegant way to get cvs log to display the date in
> local time? (I think I know the answer.) Thanks.


Sure thing...

Have your boss add the following line to his .profile

 TZ=GMT; export TZ

or the following line to his .cshrc

 setenv TZ GMT

and he will find that the output of cvs log will have dates very similar
to the 'date' command he issues. Of course, this may not work in a
Windows environment, but I am sure you get the idea.

Or, you can teach your boss the 'date -u' command.


In all seriousness, you should ask your boss if he really wants to
confuse folks who need to use your cvs repository about what time
a change was made by having it appear differently depending on the
machine in the network they happened to be logged into at the time.

I regularly login to machines in UTC-0800 UTC-0500 and UTC+0530 and it
is even more exciting when some of those machines automagically switch
to UTC-0700 UTC-0400 during daylight savings time. I expect the output
to be the same regardless of the window in which I happen to type a 
'cvs log' command. The only way to deal with world-wide development
teams is to have a single time standard used for the important stuff
and UTC is just the standard to use for cvs.

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

iD8DBQFAYfZe3x41pRYZE/gRAkBVAJ9mlFjx63qXjwA5wpFqPLlhKLMYHwCgm9tc
O9ksG/AOKJjCWjJ3Wj4uWE8=
=U4YT
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Larry Jones wrote:

>>I have been asked to "fix" this by my boss: cvs log returns the
>>timestamp of the file in Coordinated Univeral Time.  All other ways of
>>looking at the timestamp return it in local time.  Is there any quick,
>>elegant way to get cvs log to display the date in local time? (I think I
>>know the answer.) Thanks.
>
>
>No, CVS always displays times in UTC.  Because of the complexities of
>client/server mode, a lot of infrastructure would be required to support
>local time display and no one has felt compelled to do the work.


I wouldn't call a new MT tag "a lot of infrastructure".  The
implementation should be fairly straightforward and simple, I should think.

For you to use the "MT" command, there is at least one example in the
WriteLetter() function in update.c, but you should be able to find
others by grepping the source for "MT".  The handle_mt() function in
client.c would be the place where the new "datetime" tag and its text
would need to be converted into a local time.  Other than that the only
necessary change should be to avoid printing the whole line containing
the time in src/log.c, or maybe src/rcs.c, and break the line up into a
series of MT commands.

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQFAYfXxLD1OTBfyMaQRAoZwAJ9fa1XhMa4bWR3TJ9BHuC7j/uAShACgxUnO
cx1BcJCMn/gmCJNqoNOGe4M=
=c2qe
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Derek Robert Price wrote:

> I've considered this problem before but have never had the time to
> implement the solution.  The most "correct" way I have come up with is
> to add a tagged text type to the client/server protocol using the "MT"
> response type.  The client/server protocol is defined in such a way (and
> clients hopefully written in such a way) that unrecognized MT tags have
> their associated texty passed through as is.  Thus, a new tagged type
> like "datetime" could be followed by the time in UTC and old clients
> would pass through the string as is, duplicating the old log format, and
> new clients, which knew about the new "datetime" tag, could convert the
> time to local time.


By the way, there's more on CVS's client/server protocol in the
doc/cvsclient.texinfo file.  If you have a full installation of CVS and
your GNU info program is installed correctly you should be able to
access a friendly version of that document by typing `info cvsclient' at
a command prompt.  With a working but incorrectly installed GNU info and
a current CVS source distribution, something like, `info
- --directory=cvs-1.11.4/doc --file=cvsclient.info', should work too.

Derek
- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQFAYfLRLD1OTBfyMaQRAuofAKCMCexVrIW+STp46mV+tQfCOyTDvgCfWPhu
iDPMGcbfBpFShylCKxudx4I=
=D71c
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Larry Jones]

Blaney, Liza writes:
> 
> This is a multi-part message in MIME format.

Please do not send MIME and/or HTML encrypted messages to the list.
Plain text only, PLEASE!

> I have been asked to "fix" this by my boss: cvs log returns the
> timestamp of the file in Coordinated Univeral Time.  All other ways of
> looking at the timestamp return it in local time.  Is there any quick,
> elegant way to get cvs log to display the date in local time? (I think I
> know the answer.) Thanks.

No, CVS always displays times in UTC.  Because of the complexities of
client/server mode, a lot of infrastructure would be required to support
local time display and no one has felt compelled to do the work.

-Larry Jones

It's not denial.  I'm just very selective about the reality I accept.
-- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs log and UTC

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Blaney, Liza wrote:

> Message
> I have been asked to "fix" this by my boss: cvs log returns the
> timestamp of the file in Coordinated Univeral Time.  All other ways of
> looking at the timestamp return it in local time.  Is there any quick,
> elegant way to get cvs log to display the date in local time? (I think
> I know the answer.) Thanks.


I've considered this problem before but have never had the time to
implement the solution.  The most "correct" way I have come up with is
to add a tagged text type to the client/server protocol using the "MT"
response type.  The client/server protocol is defined in such a way (and
clients hopefully written in such a way) that unrecognized MT tags have
their associated texty passed through as is.  Thus, a new tagged type
like "datetime" could be followed by the time in UTC and old clients
would pass through the string as is, duplicating the old log format, and
new clients, which knew about the new "datetime" tag, could convert the
time to local time.

If you do end up implementing this, please send the patch to
<[EMAIL PROTECTED]> and to me in case the bug-cvs list is on the blink
again.  I would like to see this change go into CVS and then you
wouldn't have to maintain a local fork of CVS for your boss.

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQFAYfEpLD1OTBfyMaQRAvqJAJ9GOA3Zjsz29NTODmzTyakP+2uJugCfQ7t4
hh0N5uFa9mS9CpElX02QbZY=
=9xb4
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs