The lack of associativity is still a problem. If 2021-02-28 + 1 month = 2021-03-28,then (2021-02-28 + 1 month) + 1 month = 2021-03-28 + 1 month = 2021-04-28. While if I ask what is 2021-02-28 + 2 months (given 2021-02-28 + 1 month = 2021-03-31), most people would say 2021-04-30.
While I am not entirely sold on using awkward/"honest" names by default, the author does raise a good point: sometimes concepts are inherently messy or full of important edge cases, and we shouldn't just brush that aside.
I recently ran into a similar problem. I am implementing a distributed lock (https://www.joyfulbikeshedding.com/blog/2021-05-19-robust-di...) -- like a mutex, but works across processes and machines. I try to mimic the language's standard Mutex API as much as possible.
A normal Mutex has a query method named "owned?" to check whether the calling thread owns the mutex. When I tried implementing this method for my distributed lock, it raised a question: owned according to who? Owned according to the local state that represents the lock, or according to the state that lives in the server? Because they can differ (e.g. due to bugs in other clients or because an admin manually messed with the state). So I opted for "honest names" here too and implemented two methods: "owned_according_to_local_state?" and "owned_according_to_server_state?"
If it is important in the domain you are working in, take extra care to understand the maths that you are built on. And don't be surprised to find special cases everywhere.
Programmers exist in a world where things such as leap seconds matter. Normally if you have a timestamp that is just before a leap second, then add exactly a day's worth of seconds, you'd slide back a little in time. This might matter in another context, such as defining the limits of neighboring ranges properly. Also, who's to say the underlying precision is a second?
The intent of the library in question is to behave the way most people would. With imperfect buckets and idealized answers; yet also precision where someone makes the attempt to be specific.
None of the examples in the article use a more vague syntax, such as "0 days before the end of the month". They start with what a human might, a rounded but full date; then apply an interval. So a more clear contrived example might be.
Jan 31 .plus(1 months) => Feb 28
Jan 31 .plus(2 months) => Mar 31
Jan 31 .plus(3 months) => Apr 30
Jan 31 .plus(4 months) => May 31
Jan 1 .plus(1 months) => Feb 1
Jan 1 .plus(2 months) => Mar 1
Jan 1 .plus(3 months) => Apr 1
Jan 1 .plus(4 months) => May 1
So I’ll repeat:
What’s Feb 28th + 1 month?
Does the human expect the last day of March? Or the 28th day of March?
The API doesn’t make that clear - I think you could reasonably argue for either.
I think plus() is a name that is good enough. I can't think of a better name that will help the user understand what will happen in the 2/28 + 1 month case. That's asking too much of a method name. That's what docs are for.
When you increment the month, the result would be 2021-03-28.
The only time you'd modify the day, is if the day became invalid due to an overflow, during that increment. If, when, you overflow the days you'd set the value of days to the maximum in that month.
If I tell someone, I'll get to that in a month, they expect by this day in the next month, the next calendar page, not 30/31 days.
""" None of the examples in the article use a more vague syntax, such as "0 days before the end of the month". """
As another reply points out, it's incrementing the Month set of buckets. I'll also extend with other results I expect:
2020-12-31 .plus(1 months) => 2021-01-31
2020-12-31 .plus(2 months) => 2021-02-28
2020-12-31 .plus(3 months) => 2021-03-31
2020-12-31 .plus(4 months) => 2021-04-30
I'll go further: JodaTime probably isn't focused on Precision Date Calculations; it behaves very much the way I expect someone working with forms and fields, general CRUD enterprisy software stuff, would want auto-filled dates to work.
""" None of the examples in the article use a more vague syntax, such as "0 days before the end of the month". """
---
They asked:
""" What’s Feb 28th + 1 month?
Does the human expect the last day of March? Or the 28th day of March? """
---
It's implicit, the human only expects the month to change, because the input isn't a descriptive phrase "the end of the month" adjusted or not, it's a literal date. That's why my other test cases show the same behavior for the end of the month.
At any rate, these problems have been solved in finance, with proper date and schedule libraries.
.plus .plus .plus isn't correct because "x months" doesn't have a fixed size. You are NOT saying Base .plus(30 days), NOR are you saying Base .plus(4 weeks) ((which BTW, I'd expect to stay on the same weekday)). You're incrementing by an unstable value.
I don’t think so, no—more likely, it should be Pattern(Month)… like how would you express “second Tuesday” as a series of additions?
6÷2(1+2) = ?
We could argue about what the _right_ answer is to that equation, but I call it a trap because it's intentionally confusing and devoid of any context (or the ability to ask a follow up question). There isn't really a situation where you would see that equation and not know the intended way to interpret it... just like your question.
There are a couple of ways that context _could_ be provided though:
I'm writing an automated task that should run once per month, I don't necessarily care what day of the month it runs though since it just cleans up some temp files. If today happens to be Feb 28th, and I say run today, then every month after, I would expect it to run Feb 28th, March 28th, April 28th...
I'm writing an 'end of month' task that needs to run at the end of every month for some bookkeeping reason. If today happens to be Feb 28th, and I say run today, then every month after, I would expect it to run Feb 28th, March 31th, April 30th...
In both of these situations I would program accordingly. Computers don't understand context, that's the job of the human programming it.
The one thing nobody wants, is to add a month and land in the month one over.
So even if the semantic differs between libraries for adding a month, it actually doesn't mather that much. Because for all the other cases one could imagine, most people will add days or weeks, if staying on the same day matters.
It could mean 30 days in the future. Or the same day of the week 4 weeks in the future (i.e., 28 days in the future). Or the day of the same cardinality in next month. Or any date in the next month. And those are all equally correct.
It's simply not a precise measure of time when spoken from one human to another human in plain language. Indeed, I think we inherently understand it to be an imprecise measure of time just as much as "tomorrow" doesn't mean "exactly 86,400 seconds from this moment". "Next week" doesn't necessarily mean "7 days from now", either. That's why computers don't typically use imprecise terms. They provide feedback and say "this will occur at this time and date".
You always have to check what the operators actually do and what the requirements actually mean when you're working with times and dates.
"2021-01-31".plus(unit="Month", size=1) => "2021-02-31"
But nobody really wants that, because it's not a valid date. So implicitly the library is deciding to return a valid date.
A library could be written to just provide invalid dates, and let the end user handle any errors. That library could also include an explicit validation method that takes a date and returns a valid one.
"2021-02-31".coerceToValid() => "2021-02-28" // Overflow == Max
"2021-02-31".coerceToValid(asDays=True) => "2021-03-03" // Overflow Carries (to the right)
In fact the library, that provides an ignorant response and no contract on validity would hold to the associative property, it just wouldn't be as ergonomic.
But if the reason people are wanting to use the library, is they want something to handle the complexity for them, coercing the data is good for simplication.
There is actually another option, that provides idempotent/associative consistency and implicit coercion to valid values.
This option, which discards some use cases (days beyond 28, when manipulating months), you coerce all values 29..31 to 28. This isn't even as technically correct, as the original option, but it removes the inconsistency and holds to the simplification contract to users.
No, it doesn't.
You walk in to the doctor's office on February 28. At the desk, you see another patient about to leave. They turn to the desk attendant and say, "I'll see you in a month for my follow-up."
What date is the other patient's next appointment? What if the date you walked in had been January 31?
Also, for what it's worth, in C#:
DateTime x = new DateTime(2021, 1, 31);
x.AddMonths(1); // Feb 28
x.AddMonths(2); // March 31
x.AddMonths(1).AddMonths(1); // March 28A month is a discrete unit of measure. It is not decomposable into any number of days.
When you increment a month, you get YYYY - (MM+1). Any higher significance is maintained, but irrelevant to the operation. (This applies to the hypothetical statement in the doctor's office, the specific day is indeterminant, but can be assumed the same as current day next month.)
The fact that not all possible days exist is orthogonal to the singular meaning of the operation. It's obviously not greatly valuable to an end-user, but the method of addressing the ambiguity involves a second operation that ensures validity.
End-users want an method that does both the addition and coercion, but you can create consistency if you follow the simple path I laid out in GP.
I'll use your syntax but with the strictly correct definition of the operation.
Datetime x = new DateTime(2021, 1, 31);
x.AddMonths(1); // DateTime(2021, 2, 31)
x.AddMonths(2); // DateTime(2021, 3, 31)
x.AddMonths(1).AddMonths(1); //DateTime(2021, 3, 31)
// Ensure Valid, using a coerce to clamp overflows
DateTime(2021, 2, 31).EnsureValid(); // Feb 28
DateTime(2021, 3, 31).EnsureValid(); // Mar 31
DateTime(2021, 4, 31).EnsureValid(); // Apr 30Thank you. That's exactly it. Crazy to see how many developers don't seem to grasp it here. I guess it's the "trap" that we are used to datetimes before the time when we became developers and we have to actually relearn this stuff to get the idea.
(It is almost like a quantum state. It can be between 28 and 31 days, depending on what it's being applied to. But as soon as it's applied to an absolute date the ambiguity disappears).
If you expand out the short hand 2000-02-02 + (1 month forward from February) + (1 month forward from March), then we can see associativing is nonsensical.
In contrast if on January 31st I told them “call me two months from today” I’d expect them to call on March 31st.
It’s very intuitive.
Jan + 1 month = February, sure.
But, as soon as you add the day, it falls apart for me.
For most dates, if I add a month, in my mental model, the answer is the next month with the same date.
Jan 15 + 1 month = Feb 15, etc
But, at the edges, it gets odd quickly.
Jan 31 + 1 month = ??? Not sure, maybe Feb 28, maybe Feb 29, maybe Mar 2, maybe Mar 3. Depends on the year and who's asking me to solve the problem.
I would expect any reasonable software to fail gracefully when asked to solve this problem. And by fail gracefully, I mean ask for clarification. Or prevent me from asking silly questions in the first place.
Consider the API:
data Date = Date { getYear :: Int, getMonth :: Int, getDay :: Int }
deriving (Eq, Ord, Show)
addDays :: Date -> Int -> Date
addMonthsRounded :: Date -> Int -> Date
d `addMonthsRounded` 3
let y = (x `addMonthsRounded` 1) `addMonthsRounded` (-1)
in y == x
Also, FYI, this is not how GNU date works:
$ date -d "Jan 28 next month"
Sun Feb 28 00:00:00 CST 2021
$ date -d "Jan 29 next month"
Mon Mar 1 00:00:00 CST 2021
$ date -d "jan 31 next month"
Wed Mar 3 00:00:00 PST 2021
$ date -d "jan 30 next month"
Tue Mar 2 00:00:00 PST 2021
$ date -d "jan 1 next month"
Mon Feb 1 00:00:00 PST 2021
$ date -d "feb 28 next month"
Sun Mar 28 00:00:00 PDT 2021
$ date -d "2016-1-31 next month"
Wed Mar 2 00:00:00 PST 2016
date -d "2016-2-1 next month"
Tue Mar 1 00:00:00 PST 2016
date -d "2016-2-1 next year"
Wed Feb 1 00:00:00 PST 2017
$ date -d "2016-3-1 next year"
Wed Mar 1 00:00:00 PST 2017
The oddity in behavior I observed above is adding the length of the month of Jan to dates in Jan. I suspect only a programmer would find that inference remotely correct.
Because humans intentionally reduce the precision of their computations to make them easier.
Today = 2021-08-04
Next year = 2022
The exact month, day, hour are all unknown.
Next month = 2021-09
The exact day and hour are unknown.
Tomorrow = 2021-08-05
The hours and minutes are unknown.