[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposed datestr() changeset
From: |
Liam Groener |
Subject: |
Proposed datestr() changeset |
Date: |
Mon, 1 Mar 2010 17:08:28 -0800 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Proposed datestr() changeset,
Liam Groener <=