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

[Tatsuro MATSUOKA]

Hello

Sorry for my late response.
With http://octave.1599824.n4.nabble.com/file/n3049477/datestr.m, the error in 
time.cc from datestr
(datenum (1969, 1, 1), 0) has been disappeared.

I do not know this correction is preferable for the octave itself but at least 
solve the bug.
 
Perhaps correction of mktime on MinGw is preferable but I do not enough 
knowledge and time to fix
this.

Philip, thank you for your information.

Regards

Tatsuro
 
--- Philip Nienhuis  wrote:

> 
> 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.
> 


--------------------------------------
What is the No.1 drama, music and car of 2010 ?
    - Yahoo! JAPAN  Net BANZUKE 2010 -
http://pr.mail.yahoo.co.jp/banzuke/