Closing as a dupe of bug #36954.

@JuanPi:  AFAIK we usually close later bug reports as duplicates in favor of the earliest one.
TTBOMK the actual cause / bug / deficiency lies with strptime(); but that is no Octave function so we must relate it to a function callable in Octave. I'm indifferent to whichever that is.

Maybe we let Mike decide?

Philip - yes, I believe the same underlying bug affects both datevec and datenum. We can call this a duplicate of bug #36954. When datenum is given a string, it calls datevec to convert the string into a datevec array. And both are due to the behavior of strptime and mktime in correcting a non-existent time value into a valid time value.

Mike,

Ok got it now. Due to time changes some hours get lost and the system is aware of this, even if my TZ is empty (I guess it is getting the CET from somewhere else).

Regarding the "correct" behavior, I would say that date string should be read 'asis' no timezone awareness at all (I guess this really means that the timezone is always UTC). Let the user do the conversion.

I guess since there is no metion of timezones in the mathworks documentation that is what they do

https://ch.mathworks.com/help/matlab/ref/datevec.html

and I think they offer datetime (not implemented in Octave)

https://ch.mathworks.com/help/matlab/ref/datetime.html

to actually apply a timezone to a datestr or datevec

I would say this is the behavior implemented by the pair, strptime (system's. It is timezone unaware),  and date (GNU program. It is timezone aware).

Hi Mike,

Thanks for the effort. I still dot not understand how the current behavior is acceptable. It just misbehaves for the period of 1 hour and for that day.

1. In the first assert indeed the "_" should be erased.

2. The element-wise comparisson was intentional to show that it fails in the span of an hour

3. What do you mean by invalid time string/specification? '29/03/2009 02:00:00' is a valid time string.

4. I do not get any error with my system's strptime, it always works as expected (I would expect Octave to do the same, but maybe it is a compatibility issue). I gave the example program in comment #1

5. I get empty when getting TZ

>> getenv TZ
ans =

6. The example in comment #9 works fine here.

>> getenv TZ
ans =
>> fmt = "yyyy-mm-dd HH:MM:SS";
>> datevec ("2017-03-12 02:00:01", fmt)
ans =

   2017      3     12      2      0      1

>> datevec ("2017-03-12 03:00:01", fmt)
ans =

   2017      3     12      3      0      1

I understand that in the octave wrapper of strptime we are adding some TZ awareness. I also assume this is an inherited bug from Matlab compatibility. Right?

7. Setting TZ to UTC solves the original issue. I just wonder whether it will be triggered somewhen else.

What should the behavior of datevec be when given an invalid time string?

In my time zone there is no such thing as "2017-03-12 02:00:00". The GNU date program correctly reports an error. The next time increment after "2017-03-12 01:59:59" is "2017-03-12 03:00:00".

In your example and in your time zone, "29/03/2009 02:10:05" is an invalid time specification.

Would you prefer Octave to fold the time over by one hour the way it does now, or throw an error when given an invalid time string like this?

Or were those times recorded in UTC and you should be setting your local time zone to UTC before processing them?

juanpi - can you please show your TZ environment variable, or "timedatectl status | grep zone", or some other way so others can try with your time zone setting?

Like Dmitri I am unable to reproduce any kind of error so far.

Please note that you have a couple of mistakes.

In the original post, I think you meant "assert (vec_, vec)", which works for me.

In comment #1, I think you meant "assert (datevec ('29/03/2009 02:10:05',fmt), datevec ('29/03/2009 03:10:05',fmt))", because the != is elementwise, you want a scalar for assert. For me they are equal elementwise except for the hour position.

Could be related to bug #36954 ?
That bug is about wrong evaluation of DST in spring (I hit it because I very often work with time series of hourly measurements, and I added a patch there that I've been using w/o issues for a fairly long time now).

just to verify this appears to be linux only, on windows 7 64bit, octave 4.2.1 i get:

>> fmt = 'dd/mm/yyyy HH:MM:SS';
>> datevec ('29/03/2009 02:10:05',fmt)
ans =

   2009      3     29      2     10      5

I cannot reproduce this on Fedora 26
But may be I misunderstood your bug report.

Dmitri.

Hi,

datevec adds one hour to dates on 29/03/2009 02:*

I chased this bug down to datevec (actually I think the bug is in octave::sys::strptime)

vec        = repmat ([2009 3 29 2 0 0],6,1);
vec(:,5:6) = randi(59,6,2);  # random minutes and seconds
fmt        = 'dd/mm/yyyy HH:MM:SS';
vstr       = datestr (vec, fmt);
vec_       = datevec (vstr, fmt);
assert (vec_, vec_);

I checked that the bug is not in my system's strptime. The following program outputs the right values

#define _XOPEN_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>

int
main(void)
{
   struct tm tm;
   char buf[255];

   memset(&tm, 0, sizeof(struct tm));
   //strptime("2009-03-29 14:00:00", "%Y-%m-%d %H:%M:%S", &tm);
   //strptime("2009-03-29 02:00:00", "%Y-%m-%d %H:%M:%S", &tm);
   strptime("29/03/2009 02:00:00", "%d/%m/%Y %H:%M:%S", &tm);
   strftime(buf, sizeof(buf), "%d %b %Y %H:%M", &tm);
   puts(buf);
   exit(EXIT_SUCCESS);
}