From bug-octave-request at bevo dot che dot wisc dot edu  Mon Jan  3 11:04:43 2000
Subject: Unidentified subject!
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: Rolf Fabian <fabian at tu-cottbus dot de>
Cc: "'bug-octave UWISC'" <bug-octave at bevo dot che dot wisc dot edu>
Date: Mon, 3 Jan 2000 11:04:53 -0600 (CST)

[For some reason, your original message was not posted to the list.
Let's see if this one makes it.  --jwe]

On  3-Jan-2000, Rolf Fabian <fabian at tu-cottbus dot de> wrote:

| !! Warning !!
| millenium bug present for (precompiled) binary distribution octave 2.0.13
| ( running on win95 / cygwin32-b20 )
| 
| octave:)version
| warning: time stamp for `/octave/share/octave/site/2.0.13/miscellaneous/version.m'
| is in the future
| ans = 2.0.13
| 
| octave:)clock
| ans =
|   1970.0000     1.0000    20.0000    11.0000    16.0000    47.2230
| 
| #expected
|   2000.0000     1.0000     3.0000     .....

I don't think that this is a bug in Octave.  The clock function just
does this:

  function retval = clock ()

    tm = localtime (time ());

    retval = zeros (1, 6);

    retval(1) = tm.year + 1900;
    retval(2) = tm.mon + 1;
    retval(3) = tm.mday;
    retval(4) = tm.hour;
    retval(5) = tm.min;
    retval(6) = tm.sec + tm.usec / 1e6;

  endfunction

The localtime and time functions work the same as those in the C
library, and I believe this is the correct way to use the tm.year
value.  So I think the problem must lie elsewhere.  Check your
hardware clock.  The warning about the time stamp on the M-file being
in the future is also suspicious.

jwe



-----------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.che.wisc.edu/octave/octave.html
How to fund new projects:  http://www.che.wisc.edu/octave/funding.html
Subscription information:  http://www.che.wisc.edu/octave/archive.html
-----------------------------------------------------------------------