After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 599461 - DATEDIF issue
DATEDIF issue
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: Analytics
git master
Other All
: Normal normal
: ---
Assigned To: Morten Welinder
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2009-10-24 03:36 UTC by Andreas J. Guelzow
Modified: 2009-12-08 19:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Andreas J. Guelzow 2009-10-24 03:36:19 UTC 
=datedif(date(1901,2,28),date(1901,3,1),"d") evaluates (correctly) to 1.
=datedif(date(1900,2,28),date(1900,3,1),"d") on the other hand evaluates incorrectly to 2.

For compatibility with XL we might need to have a "skip" in the serial numbers as if there were a February 29, 1900, but functions such as datedif should account for that!
Comment 1 Morten Welinder 2009-12-08 19:26:42 UTC 
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Comment 2 Morten Welinder 2009-12-08 19:38:30 UTC 
Note, that the calculation now goes xl_serial -> dmy -> glib_julian
for both dates followed by a subtraction.  That's somewhat expensive
for something that is basically always a subtraction!

It does have the benefit of making the semantics saner: we used to
assume there was no time-of-day part of the date and get strange
results if not.