[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #59979] Unexpected format for output from date
From: |
Tasos Papastylianou |
Subject: |
[Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec |
Date: |
Sun, 31 Jan 2021 08:17:14 -0500 (EST) |
User-agent: |
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0 |
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/
- [Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec, Alan, 2021/01/30
- [Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec, anonymous, 2021/01/30
- [Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec, Tasos Papastylianou, 2021/01/30
- [Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec, Tasos Papastylianou, 2021/01/30
- [Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec, Alan, 2021/01/30
- [Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec, Tasos Papastylianou, 2021/01/30
- [Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec, anonymous, 2021/01/30
- [Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec, Markus Mützel, 2021/01/31
- [Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec, Markus Mützel, 2021/01/31
- [Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec,
Tasos Papastylianou <=
- [Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec, Tasos Papastylianou, 2021/01/31
- [Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec, Philip Nienhuis, 2021/01/31
- [Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec, Markus Mützel, 2021/01/31
- [Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec, anonymous, 2021/01/31
- [Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec, anonymous, 2021/01/31