Proposed datestr() changeset

[Liam Groener]

Hello,
I'm a relatively new Octave user. A couple of weeks ago, I ran across a bug in 
the datetick() function that was relatively straightforward to identify and 
fix. I posted the fix on the bugs list and Ben Abbott prepared and committed 
the corresponding changeset. However, in the process of testing my revised 
datetick, I noticed that tick labels for dates earlier than 1992 always had the 
wrong year, 1969.

I traced this "bug" to the function datestr() which, in turn, uses the gnulib 
function mktime(). It turns out mktime() returns 0 (corresponding to 18:59:59, 
Dec 31, 1969) for dates prior to 1902. (Ben Abbott later pinned the actual 
cut-off date/time to 12/13/1901 at 15:45:52.) Ben also reviewed the gnulib docs 
and said they implied that this mktime limitation was due to 32 bit integers. 
So, the problem may well go away with 64 bit Octave compiles. Maybe one of you 
that has already compiled a 64 bit version of Octave can verify this.

Anyway, given the existing limitation of mktime(), I revised datestr.m to work 
around this issue. Since the work-around is necessarily something of a hack, I 
thought it should be presented to the maintainers for discussion. So I prepared 
the attached changeset.

Ben sent me the Matlab output of the following command to use as part of my 
checkout of the revised function:
        datestr (datenum('Feb-28-2010') - (0:1000)*365)
This command generated 1001 dates ranging from year 1010 to 2010. The revised 
Octave datestr produced identical output. It also passed its built in tests and 
numerous other tests I preformed. It has a negligible hit on performance.

Comments?

Liam G.

changeset.patch
Description: Binary data