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

[Marco Cozzini]

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

I think I've found the same bug again. I run Octave 5.2.0 on Windows 10
Enterprise, 64-bit. Below my description.

The datenum function introduces unexpected daylight saving time (DST) issues.
I’ve found this for spring 2019 (not for autumn) and checked for 2018 as
well. According to the Octave help, datenums “do not take into account time
zones […], nor seasonal changes”. This would be perfect for me, as I use
UTC timestamps. However, it seems that sometimes DST comes in.

Sample code:
DD_0=datenum('2019/03/31 00:00','yyyy/mm/dd HH:MM');
for ii=1:4;
  my_datestr=sprintf('2019/03/31 0%d:00',ii);
  DD_r=datenum(my_datestr,'yyyy/mm/dd HH:MM');(DD_r-DD_0)*24
end

Output in Octave, issue at 02:00:
ans =  1.00000
ans =  3
ans =  3
ans =  4.0000

Output in Matlab (I have access to R2017b release) is correct:
ans =    1.0000
ans =    2.0000
ans =    3
ans =    4.0000

Could anybody confirm this is the same bug? Should the bug Status be changed
from Fixed to Open? Or should I submit a new bug report? Any workaround to
suggest?

    _______________________________________________________

Reply to this item at:

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

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