Re: datestr (datenum (1969, 1, 1), 0) does not work on octave-3.3.51+ on MinGW

[Philip Nienhuis]

Tatsuro:


Tatsuro MATSUOKA-2 wrote:
> 
> Hello
> 
> Thank you for your help.
> 
> I have tried your datestr.m 
> 
> 
> octave:1> datestr(datenum (1969, 1, 1),0)
> warning:
> d:\usr\Tatsu\mingwhome\octaves\OctBuild\hg-devel\..\..\hg\octave-work\scripts\time\datestr.m:
> possible Matlab-style short-circuit operator at line 293, column 19
>  and stopped.
> 
> However ,the above gave me a hint where the octave is stopped.
> 
>     local = localtime(mktime(tm));
> In detail, mktime(tm) makes octave in stopped state.
> 
> I consult, help of mktime
> 
> `mktime' is a function from the file
> d:\usr\Tatsu\mingwhome\octaves\OctBuild\hg-devel\src\DLD-FUNCTIONS\time.oct
> 
>  -- Loadable Function:  mktime (TM_STRUCT)
>      Convert a time structure corresponding to the local time to the
>      number of seconds since the epoch.  For example:
> 
>           mktime (localtime (time ()))
>               => 856163706
> 
>      See also: strftime, strptime, localtime, gmtime, time, now, date,
>      clock, datenum, datestr, datevec, calendar, weekday
> 
> ******************
> Then I checked struct of 
> localtime (time ())
> 
> octave:1> localtime (time ())
> ans =
> {
>   usec =  890625
>   sec =  44
>   min =  2
>   hour =  16
>   mday =  17
>   mon =  10
>   year =  110
>   wday =  3
>   yday =  320
>   isdst = 0
>   zone = JST
> }
> 
> I have investigated the structure of tm by changeing
>  
> From
> local = localtime(mktime(tm))
> to
> tm #    local = localtime(mktime(tm))
> 
> 
> The tm had the following structure.
> tm =
> {
>   year =  69
>   mon = 0
>   mday =  1
>   hour = 0
>   min = 0
>   sec = 0
>   usec = 0
>   isdst = -1
> }
> 
> I do not have enough knowledge about the time related functions.
> The orirun of octave freeze lie in mktime(tm) in my case.
> 

I've hit this one several times before, it hasn't been resolved yet.

This is related to bug 31079, see:
   http://savannah.gnu.org/bugs/?31079

On Windows (and some other OS-es) epoch = 1-1-1970, so time() (a system call
underlying mktime() ) simply cannot represent earlier dates. Same goes for
dates after 2038. Apparently the reason for the former is inability to
process negative numbers, for the latter the number of seconds since
1-1-1970 overflowing in 32 bit integers.
See e.g., here:
   http://msdn.microsoft.com/en-us/library/aa246472(VS.60).aspx
and
   http://msdn.microsoft.com/en-us/library/aa273034(v=VS.60).aspx

Datestr.m from octave-3.0.3 didn't use mktime() and behaved better outside
the date range 1970-2038 (I use that version for processing datenums
representing dates in the 19th century). Some moment after octave-3.0.3 it
was replaced by a completely rewritten version.

JWE has suggested to fix mktime() in gnulib. 
Based on googling for mktime() I get the impression that mktime() is so
deeply entangled in OS libraries and so strongly tied to number of seconds
since some epoch (-date) that in practice this may be an unreachable goal.
(But OK, I'm guessing.)

Perhaps Octave might be better off with a solution that doesn't involve
time() or mktime() at all. FWIW, That Other Program's datestr.m invokes a
mex file that takes care of converting datenum (-arrays) into a struct
similar to that returned by localtime(). AFAICS that mex file doesn't call
mktime() or time().

As my C++ proficiency is negligible I can't suggest a solution, other than
to use the datestr.m from octave-3.0.3. 
I've attached it for in case you can't uncover it (hopefully this works out
OK from Nabble). http://octave.1599824.n4.nabble.com/file/n3049477/datestr.m
datestr.m 

Philip

-- 
View this message in context: 
http://octave.1599824.n4.nabble.com/datestr-datenum-1969-1-1-0-does-not-work-on-octave-3-3-51-on-MinGW-tp3046101p3049477.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.