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

[Philip Nienhuis]

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

FYI, here's what I get on that freshly built octave-3.3.52:

address@hidden octave-3.3.52]$ ./run-octave
GNU Octave, version 3.3.52+
<snip>

octave:1> tm = localtime (time)
tm =
{
  usec =  795444
  sec =  25
  min =  35
  hour =  21
  mday =  24
  mon =  8
  year =  110
  wday =  5
  yday =  266
  isdst =  1
  zone = CEST
}

octave:2> tm.year = -23 
tm =
{
  usec =  795444
  sec =  25
  min =  35                                                                  
                           
  hour =  21                                                                 
                           
  mday =  24
  mon =  8
  year = -23
  wday =  5
  yday =  266
  isdst =  1
  zone = CEST
}

octave:3> mktime (tm)
ans = -0.20456
octave:4> localtime (mktime (tm))
ans =
{
  usec = -204555
  sec = 0
  min = 0
  hour =  1
  mday =  1
  mon = 0
  year =  70
  wday =  4
  yday = 0
  isdst = 0
  zone = CET
}

A while earlier (see the 2nd thread I mentioned some posts ago) you've asked
that same question: what are we to do?
I wouldn't know. Relying on system functions doesn't seem to work.
There is much SW around that has similar limitations: some have epoch around
1-1-1970, others around 1-1-1900. Few SW allows earlier dates.

Perhaps first of all we might need to set some goals. 
ML compatibility?
As to datenum <-> datestr, TMW says "The year 0000 is merely a reference
point and is not intended to be interpreted as a real year in time." I suppose
anything from before Pope Gregorius' intervention in October 1582 had better
be treated similarly.
So I'd opt for something that yields proper date/time (i.e. valid for
countries that followed Gregorius immediately) at least starting from October
15, 1582, 00:00:00.

Still the fact that datestr.m from Octave-3.0.3 and earlier worked OK (or
should I say:satisfactorily for me) intrigues me. While this is an Octave-only
solution, we do have it already. I have no idea about its bugs or issues, but
perhaps these bugs + issues/limitations could be fixed? Or was it just too
hopeless?


    _______________________________________________________

Reply to this item at:

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

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