dur() calculation is wrong for dates almost a year apart

[StephSabel]

What happened?

The duration between today (April 17th 2025) and April 15th 2026 is calculated as 366 days, which is more than a year.
The duration between today and a year from now (April 17th 2026) is correctly calculated as 365 days

The calculation in years using .year gives a result of over a year as well.

DQL

TABLE WITHOUT ID

dur(date("2026-04-15") - date("2025-04-17")).year as "years until 2026-04-15",

durationformat(dur(date("2026-04-15") - date("2025-04-17")), "d") as "days until 2026-04-15",

durationformat(dur(date("2026-04-17") - date("2025-04-17")), "d") as "days until 2026-04-17"

FROM #example

JS

Dataview Version

0.5.67

Obsidian Version

v1.8.9

OS

Windows

[holroy]

This is not a bug, but a feature of the luxon date library, where it assigns a given number of days to weeks, months, and so on. This leads to some wonkiness related to displaying a day difference, but nicer display when using the natural language displays.

[ja1den]

For context, here is the current implementation of the - operator for two dates.

obsidian-dataview/src/expression/binaryop.ts

Lines 115 to 119 in 5ad0994

	.register("date", "-", "date", (a, b) => {
	return normalizeDuration(
	a.diff(b, ["years", "months", "days", "hours", "minutes", "seconds", "milliseconds"])
	);
	})

Similarly, here is the current implementation of normalizeDuration.

obsidian-dataview/src/util/normalize.ts

Lines 8 to 13 in 5ad0994

	/** Normalize a duration to all of the proper units. */
	export function normalizeDuration(dur: Duration) {
	if (dur === undefined || dur === null) return dur;
	return dur.shiftToAll().normalize();
	}

Tracing it through, there are two reasons an an unexpected result is produced in the aforementioned scenario:

1. DateTime#diff returns "0 years, 11 months, 29 days, 0 hours, 0 minutes, 0 seconds, 0 milliseconds", which is correct, although when converted to days using Duration#shiftTo, results in "359 days", as 11 * 30 + 29 = 359 (Luxon "casually" converts one month to 30 days).
2. Duration#shiftToAll (called on "0 years, 11 months, 29 days, 0 hours, 0 minutes, 0 seconds, 0 milliseconds") returns "1 year, 0 months, 0 weeks, 1 day, 0 hours, 0 minutes, 0 seconds, 0 milliseconds", which converts to "366 days".

Essentially, the calls to DateTime#diff and Duration#shiftToAll both produce unexpected results on their own, and their combination exacerbates the issue.

The following JavaScript query produces the correct result:

$= dv.date("2026-04-15").diff(dv.date("2025-04-17"), "days").toHuman()

It is necessary to call Duration#toHuman explicitly, as renderMinimalDuration, which is called by Dataview's rendering logic if the value is left as a Duration, calls normalizeDuration (and therefore Duration#shiftToAll) as well:

obsidian-dataview/src/util/normalize.ts

Lines 144 to 154 in 5ad0994

	/** Render a duration in a minimal format to save space. */
	export function renderMinimalDuration(dur: Duration): string {
	dur = normalizeDuration(dur);
	// toHuman outputs zero quantities e.g. "0 seconds"
	dur = Duration.fromObject(
	Object.fromEntries(Object.entries(dur.toObject()).filter(([, quantity]) => quantity != 0))
	);
	return dur.toHuman();
	}

In summary, it's not Luxon that's producing the unexpected behaviour, but rather the way Dataview handles Durations internally. Unfortunately, without a way to control it, it's impossible to get the desired result using DQL in this case. Therefore, I'd recommend using JavaScript queries to bypass Dataview's handling entirely.

[holroy]

For context, here is the current implementation of the - operator for two dates.
...
The following JavaScript query produces the correct result:

$= dv.date("2026-04-15").diff(dv.date("2025-04-17"), "days").toHuman()

It is necessary to call Duration#toHuman explicitly, as renderMinimalDuration, which is called by Dataview's rendering logic if the value is left as a Duration, calls normalizeDuration (and therefore Duration#shiftToAll) as well:

/** Render a duration in a minimal format to save space. */
export function renderMinimalDuration(dur: Duration): string {
dur = normalizeDuration(dur);

 // toHuman outputs zero quantities e.g. "0 seconds" 
 dur = Duration.fromObject( 
     Object.fromEntries(Object.entries(dur.toObject()).filter(([, quantity]) => quantity != 0)) 
 ); 

 return dur.toHuman(); 

}
In summary, it's not Luxon that's producing the unexpected behaviour, but rather the way Dataview handles Durations internally. Unfortunately, without a way to control it, it's impossible to get the desired result using DQL in this case. Therefore, I'd recommend using JavaScript queries to bypass Dataview's handling entirely.

Sorry, if I was unprecise blaming it on Luxon, as I've not deep dived into this. Still not sure on how to handle this, but if this function produces a better result we might consider creating a datediff function for DQL. Will this only return days though? Or how would it behave for week or month diffs?

In other words, we still need a little more investigation. And I'm not sure if or when I can get around to it, but @ja1den tid was a very valuable contribution and I appreciate the effort.

[ja1den]

I think a DQL datediff function would be a good solution.

Just a wrapper around DateTime#diff would be best, in my opinion. Something like datediff(date|datetime, date|datetime, [unit]) would make it possible to control the unit in which to calculate the difference.

From what I can tell, it would also be necessary to remove the Duration#shiftToAll call from normalizeDuration, as it brings in inaccuracy due to Luxon's "casual" conversions.

As a result, it would likely be necessary to add a durationshiftto(duration, units) function as well, wrapping Duration#shiftTo, to make it possible to choose the unit in which to render Durations.

With these changes, the following would be possible:

datediff(date("2026-04-15"), date("2025-04-17"), "days") -- 363 days
durationshiftto(date("2026-04-15") - date("2025-04-17"), "days") -- 363 days

datediff(date("2026-04-15"), date("2025-04-17"), "years") -- 0.995 years
durationshiftto(date("2026-04-15") - date("2025-04-17"), "years") -- 0.995 years

I'd be happy to PR one or all of these changes. Let me know what you think!