[Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec

[Markus Mützel]

Follow-up Comment #12, bug #59979 (project octave):

I'd still argue that what Matlab seems to do is somewhat strange (hence the
item group I chose):
AFAICT, the type of datenum is double in Matlab. But still it seems to do the
conversion to a datevec vector with less than double precision.

Does it convert to single precision before conversion? Or does it do something
entirely different?

A digital clock doesn't round to the closest minute. It switches to the next
minute when that minute has started. (That's why you don't see something like
"19:60".) If you want to get output similar to what a clock would show, use
`floor`:

>> a = datenum ([2021, 1, 27, 17, 0, 0]);
>> b = datenum ([2021, 1, 27, 16, 40, 0]);
>> floor (datevec (a-b))
ans =

   -1   12   31    0   19   59


Also, the output format is completely independent of floating point accuracy
(which is the reason for the round-off errors here).
The result of `datevec` is "just a normal vector". In Octave, neighboring
elements in a vector don't interact when displayed. 
If a user prefers to round the result of `datevec` differently, they should do
that in their own code, imho.


    _______________________________________________________

Reply to this item at:

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

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