Hi Jean-Daniel: jd.b wrote: > > DATESTR function seems to bee pretty buggy :
datestr.m is in core octave, so this forum (which is about octave-forge) is the wrong place. But read on.... > * On Octave 3.2.4 Windows MinGW (from 3.2.0 ?), when the argument correspond > to a date before 1st January 1970 at 1:00. Example : > >>> datestr(now) > ans = 17-Sep-2010 16:12:57 > % it's OK > >>> datestr(datenum(1970,1,1,1,0,01)) > ans = 01-Jan-1970 01:00:01 > % still OK > >>> datestr(datenum(1970,1,1,0,59,30)) > ans = 00-Jan-1900 00:00:00 > % bad, shoud be 01-Jan-1970 00:59:30 > >>> datestr(1,'dd-mmm-yyyy HH:MM:SS') > ans = 00-Jan-1900 00:00:00 > % bad, shoud be 01-Jan-0000 00:00:00 > >>> datestr(1.0001,'dd-mmm-yyyy HH:MM:SS') > ans = 01-Jan-1970 01:00:00 > % bad, shoud be 01-Jan-0000 00:00:08 > % and why suddenly back in year 1970 and not 1900 like previous command ??? This is a known bug in octave (IIRC) 3.0.5 tru 3.2.4; I suppose this symptom is one of the reasons for gnulib in newer octave versions. More info in this thread: https://www-old.cae.wisc.edu/pipermail/bug-octave/2009-June/008887.html and especially this posting: https://www-old.cae.wisc.edu/pipermail/bug-octave/2009-June/008905.html (and if you search tru nabble (always advisable before issuing bug reports - hint!) you'll find a number of earlier reports on this issue.) The key is that the Windows system calls underlying datestr.m have limitations. For sometime the octave devs have opted for using these low-level system calls as base for datestr.m, while the competition has used a workaround. Octave from before 3.0.5 seems to have a different datestr.m version that didn't rely on mktime(), but alas! this version suffers from other bugs & limitations. Hopefully this is fixed in the development version (I can only check under Linux, the limit there used to be 1-1-1900 rather than 1-1-1970 IIRC), but at the moment there's no newer MingW octave binary than 3.2.4 so we'll have to wait until 3.4 is there.... (Perhaps Tatsuro has a working dev version to check this one out?) P. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
