Date: Fri, 21 Nov 1997 19:24:05 +0000 From: James Raynard <james@jraynard.demon.co.uk> To: jack <jack@diamond.xtalwind.net> Cc: freebsd-chat@freebsd.org Subject: Re: Tell the world about Year 2000 Compliance Message-ID: <19971121192405.00046@jraynard.demon.co.uk> In-Reply-To: <Pine.BSF.3.96.971119195318.29259A-100000@germanium.xtalwind.net>; from jack on Wed, Nov 19, 1997 at 08:09:19PM -0500 References: <19971119200333.45342@jraynard.demon.co.uk> <Pine.BSF.3.96.971119195318.29259A-100000@germanium.xtalwind.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 19, 1997 at 08:09:19PM -0500, jack wrote:
> On Wed, 19 Nov 1997, James Raynard wrote:
>
> > and assumptions about the tm_year field (which will change from a
> > 2-digit to a 3-digit field in 2000!). I've had a casual browse, but
>
> struct tm {
> [snip]
> int tm_year; /* years since 1900 */
>
> 2147483647 + 1900 = 2,147,485,547
>
> I suspect we have a few other issues to work on before the tm structure
> becomes a pressing matter. :)
I meant something like
/* Get date (in UK format) */
char datebuf[9]; /* DD/MM/YY\0 */
...
sprintf(datebuf, "%d/%d/%d", tm.tm_day, tm.tm_month, tm.tm_year);
In October 2000, there will be nine characters plus the terminating NUL
to squeeze into datebuf, which may result in Halloween arriving early.
Obviously that's not a particularly good example, but it's easy to
fall for the trap of thinking that tm_year is the number of years in
the current century and assuming 2 digits will always be enough to
hold it.
--
In theory, theory is better than practice. In practice, it isn't.
James Raynard, Edinburgh, Scotland. http://www.freebsd.org/~jraynard/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971121192405.00046>