[Octave-bug-tracker] [bug #31079] DATESTR function buggy before year 1970

[Philip Nienhuis]

Follow-up Comment #1, bug #31079 (project octave):

A nabble search shows up that this has been discussed several times before,
and not only for MingW. The most recent thread on bug-octave is here

https://www-old.cae.wisc.edu/pipermail/bug-octave/2009-June/008887.html

and M. Goffioul supplied an answer (for MingW) here:

https://www-old.cae.wisc.edu/pipermail/bug-octave/2009-June/008905.html

IMO the underlying issue is that Octave uses system calls (in MingW: mktime()
) that have limitations.

Personally I use a datestr.m from octave 3.0.3 for my octave-3.2.4
installation that doesn't suffer from this issue (don't get fooled by octave's
version):

octave-3.2.4.exe:2> datestr (datenum (1969, 1, 1), 0)
ans = 01-Jan-1969 00:00:00
octave-3.2.4.exe:3> datestr (datenum (1901, 1, 1), 0)
ans = 01-Jan-1901 00:00:00
octave-3.2.4.exe:4> datestr (datenum (1795, 1, 1), 0)
ans = 01-Jan-1795 00:00:00
octave-3.2.4.exe:5>

I need this as I often work with time series starting in the late 19th
century.
A problem with this old datestr.m seems to be (please correct me if I'm
wrong) that it doesn't accept multidimensional input (it doesn't work on
arrays). However as regards date range limitations it is more robust than
later versions.

I think the test section of datestr.m should be augmented with earlier dates
than referring to the year 2005. This bug (or limitation) would have shown up
much earlier if such tests would have been in place.
I'm not proficient enough in octave script for fixing datestr.m, but I can at
least send patches for the test section (later this week).


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?31079>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/