[Octave-bug-tracker] [bug #36954] datenum / datevec convert date-time string incorrectly during hour lost to DST

[Kai Torben Ohlhus]

Follow-up Comment #41, bug #36954 (project octave):

On my MS Windows 10 Pro (1909) VirtualBox VM I get for the script of comment
#38 the desired output.


ans =  1.00000
ans =  2.0000
ans =  3
ans =  4.0000


But this behavior might be depended on the local time zone reading the
previous posts.  I am in Japan (JST) and they do not have DST that might be
the reason.

On the other hand, it is documented in datenum, that Octave does not handle
DST correctly.

https://www.octave.org/doc/v5.2.0/XREFdatenum.html

> Caution: datenums represent a specific time for the Earth as a a whole. They
do not take in to account time zones (shifts in time based on location), nor
seasonal changes due to Daylight Savings Time (shifts in time based on local
regulation). Be aware that it is possible to create datenums that, when
interpreted by a function which accounts for time zone and DST shifts such as
datestr, are nonexistent or ambiguous. 

My conclusion is, to either just close this again as won't fix, or someone has
to overhaul the timing features and test them in different time zones.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?36954>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/