Wed 23 Aug 2017 07:56:45 AM UTC, comment #20:
Closing as a dupe of bug #36954.
|
Sun 02 Jul 2017 03:47:22 AM UTC, comment #19:
output from Mike's request in comment #13:
|
Sat 01 Jul 2017 10:30:13 AM UTC, comment #18:
@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?
|
Sat 01 Jul 2017 02:55:07 AM UTC, comment #17:
Not so important, but the bug dependence seems inverted. datenum calls datevec calls strptime.
|
Fri 30 Jun 2017 09:19:57 PM UTC, comment #16:
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.
|
Fri 30 Jun 2017 08:11:59 PM UTC, comment #15:
I'm not convinced that the underlying issue is different than bug #36954.
The issue there is in the end identical to what is shown in comment #9 here.
That this bug is about datevec.m is a red herring - what matters is that any function that in the end relies on strptime() is affected.
What I found -after some web-searching- is that what strptime() does for non-existent times is implementation-dependent - see bug #36954 comment #11.
Octave apparently uses a "faulty" strptime() implementation.
|
Thu 29 Jun 2017 11:08:14 PM UTC, comment #14:
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).
|
Thu 29 Jun 2017 10:38:23 PM UTC, comment #13:
What I mean is that this wallclock time does not exist in your local time zone. If you had been recording some kind of time series data at say one minute intervals on your system, the data log would have gone from "01:58:00" to "01:59:00" to "03:00:00" because the hour between 02:00:00 and 02:59:59 does not exist on that particular day.
When I use GNU date to try to parse such a date string, I get back a definitive error:
If you adjust your C program to look at the time_t value returned by mktime(), you'll see that that value actually represents 03:00:00:
That's what I mean when I say that this example time is specifying an invalid / nonexistent time in your time zone.
There may be a Matlab compatibility issue here, from comment #11 it looks like Matlab parses the string into a datevec regardless of whether it can represent a valid time or not.
nrjank - since you have Matlab 2017 available, and you're on the same US timezone rules, can you try the following:
In Octave I get
|
Thu 29 Jun 2017 08:32:46 PM UTC, comment #12:
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
6. The example in comment #9 works fine here.
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.
|
Thu 29 Jun 2017 08:28:32 PM UTC, comment #11:
correcting my earlier comment #4, my timezone behaves similarly to Mikes, although I don't have a TZ env variable. Don't know what the equivalent is in Windows. (local TS is EDT/EST, UTC-4/-5)
If we want to consider compatibility, the Matlab 2017a behavior seems to ignore this issue:
|
Thu 29 Jun 2017 07:49:50 PM UTC, comment #10:
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?
|
Thu 29 Jun 2017 07:42:13 PM UTC, comment #9:
I can reproduce what I think you are reporting with the following here:
|
Thu 29 Jun 2017 07:38:10 PM UTC, comment #8:
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.
|
Thu 29 Jun 2017 06:18:53 PM UTC, comment #7:
It might be, but the issue is really datevec not datenum.
also it the underlying system function works fine...so it is somewhere between datevec and strptime
|
Thu 29 Jun 2017 04:49:39 PM UTC, comment #6:
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).
|
Thu 29 Jun 2017 03:27:35 PM UTC, comment #5:
hg id
251cb33c6570 tip @
(same with 4.2.1)
Dmitri.
--
|
Thu 29 Jun 2017 01:37:10 PM UTC, comment #4:
just to verify this appears to be linux only, on windows 7 64bit, octave 4.2.1 i get:
|
Thu 29 Jun 2017 11:27:03 AM UTC, comment #3:
Dmitri,
Thanks for checking, hat do you get if you do
|
Thu 29 Jun 2017 11:11:11 AM UTC, comment #2:
I cannot reproduce this on Fedora 26
But may be I misunderstood your bug report.
Dmitri.
|
Thu 29 Jun 2017 08:20:32 AM UTC, comment #1:
Another way of triggering the bug is
|
Thu 29 Jun 2017 07:57:29 AM UTC, original submission:
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)
I checked that the bug is not in my system's strptime. The following program outputs the right values
|