Search

On Saturday, 10 February 2024 at 15:53:09 UTC, Alexander Zhirov wrote:

>

Is it possible to calculate the difference between dates in years using regular means? Something like that

``````writeln(Date(1999, 3, 1).diffMonths(Date(1999, 1, 1)));
``````

At the same time, keep in mind that the month and day matter, because the difference between the year, taking into account the month that has not come, will be less.

My abilities are not yet enough to figure it out more elegantly.

Maybe I'm not understanding the question, but why not that result / 12?

-Steve

```On Saturday, February 10, 2024 4:20:33 PM MST Steven Schveighoffer via Digitalmars-d-learn wrote:
> On Saturday, 10 February 2024 at 15:53:09 UTC, Alexander Zhirov
>
> wrote:
> > Is it possible to calculate the difference between dates in years using regular means? Something like that
> >
> >
> > ```
> > writeln(Date(1999, 3, 1).diffMonths(Date(1999, 1, 1)));
> > ```
> >
> > At the same time, keep in mind that the month and day matter, because the difference between the year, taking into account the month that has not come, will be less.
> >
> > My abilities are not yet enough to figure it out more elegantly.
>
> Maybe I'm not understanding the question, but why not that result / 12?

If I understand correctly, he cares about how far into the month the dates
are, whereas diffMonths ignores the smaller units, meaning that you get the
same result no matter when in the month the dates are. So,
2000-05-10 - 1990-05-09 would give 10, whereas 2000-05-10 - 1990-05-30
would give 9. diffMonths / 12 would give 10 in both cases.

- Jonathan M Davis

```
```On Saturday, 10 February 2024 at 22:11:48 UTC, Brad Roberts wrote:
> Back when I was doing lots of software developer interviews, one of my frequent questions involved date math.  This wasn't because it's difficult from a coding standpoint, but that it's NOT a coding problem. The key part of the question is realization that it's a requirements question.  The thing that makes dates complicated is defining what the question actually is.
>
> The topic _seems_ like it should be simple, but the deeper you dig the more you realize it's anything but simple.
>

Interesting but I have a doubt, they (Interviewees) should do the test with already existing Date Functions of given language or write new ones?

Matheus.
```

On Saturday, 10 February 2024 at 23:48:56 UTC, Jonathan M Davis wrote:

>

If I understand correctly, he cares about how far into the month the dates
are, whereas diffMonths ignores the smaller units, meaning that you get the
same result no matter when in the month the dates are. So,
2000-05-10 - 1990-05-09 would give 10, whereas 2000-05-10 - 1990-05-30
would give 9. diffMonths / 12 would give 10 in both cases.

I thought `diffMonths` was actually already taking this into account...

Looking at the impl, it's pretty simple.

Would it make sense to have an overload that takes into account the day as well as the month/year? This kind of stuff is sometimes tricky to get right.

-Steve

On Saturday, 10 February 2024 at 15:53:09 UTC, Alexander Zhirov wrote:

>

Is it possible to calculate the difference between dates in years using regular means? Something like that

``````writeln(Date(1999, 3, 1).diffMonths(Date(1999, 1, 1)));
``````

At the same time, keep in mind that the month and day matter, because the difference between the year, taking into account the month that has not come, will be less.

My abilities are not yet enough to figure it out more elegantly.

OK, so I thought this was already taking into account the day of the month.

This is what I came up with:

``````int diffMonthNew(Date d1, Date d2)
{
auto diff = d1.diffMonths(d2);
if(diff > 0)
return diff + (d1.day < d2.day ? -1 : 0);
else if(diff < 0)
return diff + (d1.day > d2.day ? 1 : 0);
return 0;
}
``````

Then if you want the years, it would be `diffMonthNew(d1, d2) / 12`

-Steve

```On Saturday, February 10, 2024 7:31:47 PM MST Steven Schveighoffer via Digitalmars-d-learn wrote:
> On Saturday, 10 February 2024 at 23:48:56 UTC, Jonathan M Davis
>
> wrote:
> > If I understand correctly, he cares about how far into the
> > month the dates
> > are, whereas diffMonths ignores the smaller units, meaning that
> > you get the
> > same result no matter when in the month the dates are. So,
> > 2000-05-10 - 1990-05-09 would give 10, whereas 2000-05-10 -
> > 1990-05-30
> > would give 9. diffMonths / 12 would give 10 in both cases.
>
> I thought `diffMonths` was actually already taking this into account...
>
> Looking at the impl, it's pretty simple.
>
> Would it make sense to have an overload that takes into account the day as well as the month/year? This kind of stuff is sometimes tricky to get right.

Possibly. Given the trickiness involved, there probably should be a function in std.datetime to handle it, but I'll have to think about what the best way to do it would be in terms of the API.

It is kind of similar to how some functions behave differently depending on how you want to treat the end of the month (e.g. whether adding a month to May 31st gives you June 30th or July 1st), but it's also not quite the same. So, the enum related to that wouldn't be appropriate, but it's yet another edge case where sometimes you want one behavior, and at other times, you want the other behavior.

- Jonathan M Davis

```
```On 2/10/2024 6:01 PM, matheus via Digitalmars-d-learn wrote:
> On Saturday, 10 February 2024 at 22:11:48 UTC, Brad Roberts wrote:
>> Back when I was doing lots of software developer interviews, one of my frequent questions involved date math.  This wasn't because it's difficult from a coding standpoint, but that it's NOT a coding problem. The key part of the question is realization that it's a requirements question.  The thing that makes dates complicated is defining what the question actually is.
>>
>> The topic _seems_ like it should be simple, but the deeper you dig the more you realize it's anything but simple.
>>
>
> Interesting but I have a doubt, they (Interviewees) should do the test with already existing Date Functions of given language or write new ones?
>
> Matheus.

My interviews were never tests, they were discussions that might also involve coding tasks.  In this case, the discussion was about requirements gathering disguised initially as a coding task.  By and large, I never put a lot of weight on the coding parts themselves and mostly focused on problem solving and thinking skills.  If the candidate couldn't get past writing code and wouldn't ask questions, that was a very bad sign.
```
1 2
Next ›   Last »