Bug 9946 - Various date problems, probably leap year?
Summary: Various date problems, probably leap year?
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rcs   
(Show other bugs)
Version: 6.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-03-04 00:39 UTC by dannyw
Modified: 2015-03-05 01:08 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-03-05 04:00:25 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description dannyw 2000-03-04 00:39:06 UTC
-->I noticed the date was wrong (Probably not a RedHat problem):
[root@edsm_www employees]# date
Sat Mar  4 19:17:57 EST 2000

-->So I tried to set it (and got it wrong again):
[root@edsm_www employees]# date 030419192000
Sat Mar  4 19:19:00 EST 2000
[root@edsm_www employees]#

--> Then I wondered what rcs had been thinking:
head -2 findspe.cgi
#!/usr/bin/perl -T -w
# $Id: findspe.cgi,v 1.6 2000/03/05 00:17:05 root Exp root $

-->Huh! It was storing 3/5? And what's with the time? (I was just editing
-->that file...)
-->Well -- let's fix the date properly and see what happens...
root@edsm_www employees]# date 030319382000
Fri Mar  3 19:38:00 EST 2000
[root@edsm_www employees]# co -l findspe.cgi
RCS/findspe.cgi,v  -->  findspe.cgi
revision 1.6 (locked)
[root@edsm_www employees]# vi findspe.cgi
[root@edsm_www employees]# ci -u findspe.cgi
RCS/findspe.cgi,v  <--  findspe.cgi
ci: RCS/findspe.cgi,v: Date 2000/03/04 00:38:31 precedes 2000/03/05
00:17:05 in revision 1.6.

-->Well, I suppose rcs is doing what it's supposed to in detecting that the
-->date sequence is backwards... but it's STILL off by a day! And the
-->time is still strange too.

Comment 1 Jeff Johnson 2000-03-05 04:00:59 UTC
I can't reproduce this problem.

First, rcs uses UTC within $Id$, so that explains the time difference. You
checked in with the system time a day off, that explains the failed sanity
check (just edit the ,v file to fix).

I do not see any sign of a Y2K problem either with the year or leap day.

Note You need to log in before you can comment on or make changes to this bug.