Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Tony Hoyle wrote: >> It seems that update -D requires local time rather than UTC. I suspect it's >> the client's local time, but haven't had a chance yet to test this. > > I'm not sure.. the date parser is inherited from the old cvs (and > predates even that I think). Wow... I only remember having read in everything I read about cvs that dates/times are in UTC. All of them... I don't remember having read anything about local time being used /anywhere/. But according to you this seems to have been in cvs/cvsnt for a loooong time. Did I just miss this in the docs, or is this really strange? >> Maybe this is the result of having a system developed on the Greenwich >> meridian... it might have been safer to put the UTC meridian somewhere in >> the Pacific :) > Not my fault!! :) Probably not, I was just kidding :) But did this never come up during testing? I mean, I don't use the update to date option a lot (in fact, almost never). But the moment someone uses it (which probably happens during testing) who's not on UTC, it is pretty obvious that there's a difference between the date/time sent with the command and the resulting sticky date. Yet I don't remember having read about this in any documentation of cvs/cvsnt. You probably have a test case for the update -D option in your test suite, don't you? What does this test case say about this? Gerhard