From owner-freebsd-hackers Sun Jun 1 16:21:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA13110 for hackers-outgoing; Sun, 1 Jun 1997 16:21:57 -0700 (PDT) Received: from hps.sso.wdl.lmco.com (hps.sso.wdl.lmco.com [158.186.22.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id QAA13100 for ; Sun, 1 Jun 1997 16:21:53 -0700 (PDT) Received: from hps (hps.sso.wdl.lmco.com) by hps.sso.wdl.lmco.com (4.1/SSO-4.01-LMCO) id AA09888; Sun, 1 Jun 97 19:12:47 EDT Date: Sun, 1 Jun 1997 19:12:47 -0400 (EDT) From: Richard Toren X-Sender: rpt@hps To: freebsd-hackers@FreeBSD.ORG Subject: Re: fetch In-Reply-To: <199705312112.RAA02809@radford.i-plus.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I think this type of thinking ("assume current century") is how the 2-digit years got started; and what got us into the 2K problem. The boundry conditions are where that assumption breaks. Clock drift or just lucky timing has the item dated 12-31-99 23:58 and received 1-1-00 00:03. Was it sent 99 years in the future? The next kludge is to create some special cases where the data appears too far in the future to be a clock sync problem (99 years?). But even that will break in some cases where 5 years may be reasonable.... Best not depend (do anything destructive) upon any date that is ambigious.... On Sat, 31 May 1997, Troy Settle wrote: > From: Terry Lambert > >> Hi, > >> > >> My ISP (demon.co.uk) sends http dates like this: > >> > >> Sat, 31-May-97 10:48:56 GMT > >> > >> According to http.c in the fetch sources, it's expecting > >> a full year here, ie. > >> > >> Sat, 31-May-1997 10:48:56 ..... > >> > >> Has anyone any objection to me making it allow the first ? > > > >As long as you treat it as the year 0097, no objection at all; > >otherwise you are introducing a year 2000 error. > > > >Has demon refused to correct their server software? Or have > >they not been asked? > > > > Why not treat a 2 digit year as a year in the current century? no > y2k problem. no y3k problem, etc.. > > Really though, a 2 digit year is just a lazy way of writing the date. > It's human readable, but is a pain for software to interpret > correctly. There's no reason for any software to use a 2 digit year > except for formatted user input/output. > > Just an opinion, > > -- > Troy Settle > Network Administrator, iPlus Internet Services > http://www.i-Plus.net > > > ==================================================== Rip Toren | The bad news is that C++ is not an object-oriented | rpt@sso.wdl.lmco.com | programming language. .... The good news is that | | C++ supports object-oriented programming. | | C++ Programming & Fundamental Concepts | | by Anderson & Heinze | ====================================================