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

[Tasos Papastylianou]

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

Hi Markus!

Just to clarify, the point of that example is not the year-month-day
difference (I agree that the octave representation makes more sense). Whether
*that* part should be treated as a "wtf matlab" bug or not is an entirely
unrelated issue to this bug report (and personally, I would not fix that
part)

The main issue here is the rounding of [19, 59.999] to [19, 60.0] as opposed
to [20, 0] in the resulting datevec vector, when operating at a particular
output precision!

Matlab does this "correctly" (imo), under the assumption that the datevec is
to be interpreted as a structure conveying time semantics, despite the fact
that functionally it is a normal array. Therefore [19, 60] is meaningless: in
the same way there is no "zero" date on a calendar, there is no "19:60" time
on a clock.

I appreciate how the 60 may have come about as a rounding of 59.99. The
argument is, since a datevec generated vector represents time semantics, such
a rounding should be treated in time semantics as well, and therefore round
[19, 59.99] to [20, 0] instead (as matlab does it).

However I also appreciate the argument that this is simply a representational
issue w.r.t. a particular output_precision, and the underlying precision does
not change. And also that passing this to datestr will produce the expected
result.

Therefore the solution to this bug (at least from a 'differs from matlab'
point of view) is either:
A) to fix it, i.e. detect the output precision before rounding, and round
appropriately using time semantics *before* returning the resulting datevec,
in a way compatible with matlab,
OR
B) leave it as it is, (i.e. incompatible with matlab) but perhaps add a simple
'caveat emptor' note in the documentation that the datevec output is not
rounded using time semantics, and should therefore be treated with caution,
i.e. it should not be relied on for inspecting individual elements of a date
for equality in this fashion (and that the right way to do this is via string
representations or floating-point calculations involving datenum, and the
usual caveats involving comparisons in floating-point arithmetic).

My personal opinion is that B is probably better than A, since one presumably
does not want to 'lose' actual precision in the seconds for the sake of output
precision, and I don't necessarily think that [2000, 1, 1, 0, 20, -0] is
particularly better than [2000, 1, 1, 0, 19, 60] in denoting 'a small number
of milliseconds short of the full minute'.

    _______________________________________________________

Reply to this item at:

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

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