Thu 16 Mar 2017 04:17:43 PM UTC, comment #14:
I pushed the patch under your name to the stable branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/92d60bf45889). I added some BIST tests for fractional years as well.
I'm going to close this report, finally!
|
Thu 16 Mar 2017 04:07:52 AM UTC, comment #13:
I attached a patch that hopefully handles fractional years correctly now. I left the current code untouched for normal years and have added some lines which are called just in case of fractional years.
Btw: It is not a good idea to test datenum using datestr as datestr calls datenum itself. Better use datevec.
(file #40011)
|
Wed 15 Mar 2017 11:44:30 PM UTC, comment #12:
The problem with fractional years was present in 4.2.1 so at least we haven't introduced anything new with our changes. I'm sure this is related to some odd shifting of the start of the year. The code is
Whatever we are doing, I would expect it to cause problems for Jan. and Feb. Indeed, that is what this code shows.
@Lars: Do you want to take a look at this one? It looks to me like in the lookup for number of days since the start of the current year the constant +60 needs to be +61 for leap years.
|
Wed 15 Mar 2017 11:33:29 PM UTC, comment #11:
I pushed the change for fractional months and the syntax
See http://hg.savannah.gnu.org/hgweb/octave/rev/a21f8372bb76.
|
Wed 15 Mar 2017 11:21:30 PM UTC, comment #10:
Sorry, there is still a glitch in datenum(), this time with fractional years:
or, better visible here:
The number of days in a year used in the calculation seems to ignore leap years.
|
Wed 15 Mar 2017 10:57:40 PM UTC, comment #9:
Yes, datestr() seems to use only the first entry in an array to auto-select the format. If time there is zero, all other rows also display the date only. I was fooled by that. Perhaps that should be changed in datestr(). datenum() works fine for me now.
|
Wed 15 Mar 2017 08:38:55 PM UTC, comment #8:
I think everything is working correctly. For the last example, it appears that datestr has chosen a different output format because the hour field is precisely aligned at 00 and 12. If I force datestr to use a long format (format 0) then this is what I get.
|
Wed 15 Mar 2017 01:58:40 PM UTC, comment #7:
this works fine now:
add one hour
that looks good, too, same with 11 hours
but what happens with 12 hours on non leap years?
I slowly understand why matlab people decided to not support fractional month but just round it down...
|
Tue 14 Mar 2017 08:15:09 PM UTC, comment #6:
I'm attaching a proposed changeset. Please verify that it works for the corner cases you have in mind.
(file #40005)
|
Mon 13 Mar 2017 09:19:02 PM UTC, comment #5:
@Lars: Let me try. I know exactly where the code is that I want to change.
|
Mon 13 Mar 2017 08:58:42 PM UTC, comment #4:
@Rik Are you already working on it or shall I give it a try?
|
Mon 13 Mar 2017 03:14:42 PM UTC, comment #3:
Confirmed. The part of the code that exands all inputs to common size occurs after the fractional month calculation. The program flow should probably be:
1) Validate inputs
2) Convert to common format (strings->datevec) and common size
3) Perform datenum calculation
|
Mon 13 Mar 2017 11:31:00 AM UTC, comment #2:
datenum() still crashes for fractional month using the other calling convention: datenum(year,month,day):
+verbose+
>> datestr(datenum(2000:2003,2,1))
ans =
01-Feb-2000
01-Feb-2001
01-Feb-2002
01-Feb-2003
-verbose-
works, but
+verbose+
>> datestr(datenum(2000:2004,2.5,1))
error: fracmonth(4): out of bound 1
error: called from
datenum at line 135 column 14
-verbose-
|
Sun 12 Mar 2017 06:30:09 PM UTC, comment #1:
I decided to fix this on the stable release since Octave shouldn't be generating errors for legal inputs. I checked in a changeset here (http://hg.savannah.gnu.org/hgweb/octave/rev/afa48a26e684) that adds support for fractional months and some specific tests for fractional months and leap years.
|
Fri 10 Mar 2017 05:44:33 PM UTC, original submission:
datenum() allows integer and fractional month inputs:
However, if fed with an array of dates, it crashes when any month value is not integer:
This patch solves the problem:
Remark: there is some incompatibility with matlab which simply trunctates fractional month while octave adds respective days. See Bug #50493 comment #4 for details.
|