Error in datestr.m in Octave-3.2.0 MingW

[Philip Nienhuis]

John W. Eaton wrote:
> On 22-Jun-2009, Philip Nienhuis wrote:
> 
> | Octave's function datestr.m fails for dates before Jan 2, 1970 in the
> | MingW build 3.2.0:
> | 
> | **********************<screen copy:>*********************************
> | 
> | GNU Octave, version 3.2.0
> | Copyright (C) 2009 John W. Eaton and others.
> | This is free software; see the source code for copying conditions.
> | There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
> | FITNESS FOR A PARTICULAR PURPOSE.  For details, type `warranty'.
> | 
> | Octave was configured for "i686-pc-mingw32".
> | 
> | Additional information about Octave is available at http://www.octave.org.
> | 
> | Please contribute if you find this software useful.
> | For more information, visit http://www.octave.org/help-wanted.html
> | 
> | Report bugs to <bug at octave.org> (but first, please read
> | http://www.octave.org/bugs.html to learn how to write a helpful report).
> | 
> | For information about changes from previous versions, type `news'.
> | 
> | warning: mark_as_command is obsolete and will be removed from a future
> | version of Octave
> | octave-3.2.0 > datestr(datenum(1970, 1, 1))
> | ans = 00-Jan-1900
> | octave-3.2.0 > datestr(datenum(1970, 1, 2))
> | ans = 02-Jan-1970
> | octave-3.2.0 >
> | 
> | **********************</screen copy>*********************************
> | 
> | The previous 3.0.3 VC++ Windows build is OK in this respect.
> | 
> | I haven't checked other binary octave versions yet.
> | 
> | While perusing the source code of datestr.m I couldn't find the spot
> | where the actual conversion takes place (but then again I'm neither an 
> | octave nor a C++ guru).
> | (Speculation (sorry): I suspect the use of strftime() may be related to 
> | this.)
> 
> Yes, it uses strftime.  It seems to work for me on my Debian system:
> 
>   octave:1> datestr(datenum(1970, 1, 1))
>   ans = 01-Jan-1970
>   octave:2> datestr(datenum(1969, 1, 1))   
>   ans = 01-Jan-1969
>   octave:3> datestr(datenum(1929, 1, 1))
>   ans = 01-Jan-1929
> 
> I guess strftime is broken on MinGW?  I think the proper place to fix
> that is in the MinGW C library.

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.


- OS/2 build 3.0.0: WORKS OK
*********************<screen copy:>*********************************
GNU Octave, version 3.0.0
<snip>
Octave was configured for "i386-pc-os2-emx".
<snip>
octave:1> datestr(datenum(1950,7,21))
ans = 21-Jul-1950
octave:2> date_str(datenum(1950,7,21))
ans = 21-Jul-1950
octave:3>
**********************</screen copy>*********************************
So EMX (the OS/2 POSIX stuff) seems robust....


- Linux (Mandriva 2009.1): WORKS OK
*********************<screen copy:>*********************************
GNU Octave, version 3.0.3
<snip>
Octave was configured for "i586-mandriva-linux-gnu".
<snip>
octave:1> datestr(datenum(1962, 8, 9))
ans = 09-Aug-1962
octave:2> date_str(datenum(1962, 8, 9))
ans = 09-Aug-1962
octave:3>
**********************</screen copy>*********************************
... and the linux runtime libs too.

So, a provisional conclusion might be that date_str.m (the datestr.m 
from Octave-3.2.0) fails only on Windows systems (!)

With my limited octave / C++ programming insight I'm out of options
here, sorry.

Hopefully someone else can figure out what is going wrong here....

Philip