Error in datestr.m in Octave-3.2.0 MingW

[John W. Eaton]

On 23-Jun-2009, Philip Nienhuis wrote:

| If so, yes.
| 
| But: before bothering the MingW people it should be certain that
| strftime() is indeed the culprit.
| I'm not (yet) sufficiently proficient in octave or C++ to be able to 
| prove this sufficiently.
| 
| But what I could do and did is trying the erroneous datestr.m from
| octave-3.2.0-MingW in several other octave versions (I've called it
| date_str there, to distinguish it from the datestr.m belonging to the 
| tried octave versions):
| 
| 
| - Windows 3.0.3VC++: FAILS
| *********************<screen copy:>*********************************
| GNU Octave, version 3.0.3
| <snip>
| Octave was configured for "i686-pc-msdosmsvc".
| <snip>
| octave-3.0.3.exe:1> datestr(datenum(1945,7,8))
| ans = 08-Jul-1945
| octave-3.0.3.exe:2> date_str(datenum(1945,7,8))
| ans = 00-Jan-1900
| octave-3.0.3.exe:3>
| **********************</screen copy>*********************************
| So MingW or VC++ makes no difference; the datestr.m (date_str.m) from 
| octave-3.2.0 fails on both.

OK.  Does the generated config.h file for Octave define HAVE_STRFTIME?
You can also look at the output of

  octave_config_info ("DEFS")

If HAVE_STRFTIME is not defined on these systems, then the bug is
likely in the strftime.c that is part of Octave.  Maybe we need to
find a newer version.

jwe