News for hackers. Stuff that matters.
Re:Fixing a Small Calc.exe Bug by DigitalTerminal on Wednesday June 19, 2019 @02:47AM (#20221310)
Time is hard. But like what does it even mean to say something is 4 months away when the months could be different lengths? 4 months is a shorter time if that period includes the end of February. This fixed result is strange but does it even matter?
Re:Fixing a Small Calc.exe Bug by tremon on Wednesday June 19, 2019 @04:50AM (#20221786)
what does it even mean to say something is 4 months away when the months could be different lengths?

The same thing it means when something is 2 years away when the years could be different lengths?

The month is a well-defined unit within the context of a certain calendar. And since a normal date representation contains the month as a singular component, month additions are usually well-defined (the obvious exception being, adding N months to yyyy-mm-31 -- the result is undefined, though most people will assume it to refer to the first day of the month following).

There is no need to bring mathematical strictness into it, because months are never used for that purpose. Moreover, no calendar system is built for mathematical strictness anyway, so arguing for that kind of strictness is like building a house on quicksand.

Re:Fixing a Small Calc.exe Bug by mywittyname on Wednesday June 19, 2019 @01:01PM (#20225027)
> though most people will assume it to refer to the first day of the month following

I wouldn't, I'd assume it's the last day. For me, any date that is "two months after" any date in July should fall in September, with the days longer than the target month scaling down. So two months after July 31 should be, to me, September 30.

But,

    $ date -d "2019-07-31 +2 months"
    Tue, Oct  1, 2019 12:00:00 AM
Suggests I'm in the minority.
Re:Fixing a Small Calc.exe Bug by ygra on Friday June 21, 2019 @01:58AM (#20240206)

    > (date 2019-07-31).AddMonths(2)

    Montag, 30. September 2019 00:00:00
.NET agrees, though :)

For software libraries it's a bit of a pickle, though, as you have the trade-off between »do what an end user would expect« and »do exactly as told, and let the programmer deal with the weirdness«. Admittedly, adding months is something that I'd rarely do as a programmer when the context isn't what a user would expect. Adding 30 days can be done in much the same way if that's really what's intended.

Interesting question, though: Is 2 months from 2019-07-28 2019-09-28 because the day part is the same, or 2019-09-27 because it's three days from the end of the month? ;-)

Re:Fixing a Small Calc.exe Bug by bscphil on Wednesday June 19, 2019 @04:57AM (#20221819)
You're right, but I think the problem does arise for "four and a half months away". That actually requires you to pin down how many days are in a month.
Re:Fixing a Small Calc.exe Bug by mannykannot on Wednesday June 19, 2019 @07:01AM (#20222272)
There is -- or should be -- an understanding that when such a phrase is used, it is not intended to be taken as a precise duration. Furthermore, for any of these expressions, while there is not necessarily just one moment in time that it is equivalent to, there is a vast range of times that it definitely does not denote.
Re:Fixing a Small Calc.exe Bug by gumby on Wednesday June 19, 2019 @05:30AM (#20221970)
It only requires you to know how many days are in each month, and you have to know what you’re counting. That’s the problem with calc: it discards the semantics of “how I got here,”
Re:Fixing a Small Calc.exe Bug by organsnyder on Wednesday June 19, 2019 @08:28AM (#20222653)
I think it's more complicated, and depends on assumptions made by the speaker and the listener: if I say "two and a half months from now", is the half-month equal to 15 days or 14? If the target duration is February, perhaps I'd assume 14; but otherwise I probably assume 15; but what if February is one of the whole months in between?

In my experience (in my culture), we avoid these problems by just assuming that we'd never convey a precise date in this manner: anything more than a week away we tend to convey with the exact date (March 15th); or, we might say "exactly two weeks from today" or "exactly one month ago" (implying the same numerical day-of-month, regardless of how long each month is), but I don't think we'd ever say "exactly one and a half months from now".

And this is why calendars are hard: it's as much (or more) anthropology as it is arithmetic.

Re:Fixing a Small Calc.exe Bug by GrinningFool on Wednesday June 19, 2019 @01:51PM (#20225432)
True, but you wouldn't use that in a context where precision is required. You'd say something like '31 weeks' if the specific duration mattered, or just the date itself. When the exact duration isn't particularly relevant, the ambiguous 'four and a half months' works just fine.
Re:Fixing a Small Calc.exe Bug by rukuu001 on Wednesday June 19, 2019 @07:01AM (#20222271)
One of my first gigs we did a LOT of work with a Sybase database. Backend code frequently made calls to the Sybase database for no reason other than to use the DATEADD and DATEDIFF functions because they were so reliable and easy to use (except for being in a database).
Re:Fixing a Small Calc.exe Bug by slim on Wednesday June 19, 2019 @07:00AM (#20222264)
Dates are actually always durations. But most time libraries design fail to aknowledge that. When you say something is 4 months away, it means you're probably happy with a 1 month resolution. 4 months from 31 July is November. 4 months from any day in July is always November.
Re:Fixing a Small Calc.exe Bug by jimktrains2 on Wednesday June 19, 2019 @09:11AM (#20222967)
But 4 months from July 31 is Dec 1.
Re:Fixing a Small Calc.exe Bug by granshaw on Wednesday June 19, 2019 @09:37AM (#20223202)
Talk to any non programmer or mathematician on the street (aka your users) and they’ll expect the answer to be Nov 30.
Re:Fixing a Small Calc.exe Bug by anchpop on Wednesday June 19, 2019 @11:54AM (#20224433)
Reminds me of the old joke, why do programmers confuse Halloween and Christmas? Because DEC 25 is OCT 31
Re:Fixing a Small Calc.exe Bug by slim on Wednesday June 19, 2019 @09:36AM (#20223189)
that's 123 days from July 31 not 4 months from July 31
Re:Fixing a Small Calc.exe Bug by ngcc_hk on Wednesday June 19, 2019 @04:47AM (#20221775)
Agree, hard even though one may say a minor program.