pub fn duration_component(
months: i64,
days: i64,
seconds: i64,
nanos: i32,
prop: &str,
) -> Option<i64>Expand description
d.<prop> component access for a Duration – every field (years,
quarters, months, weeks, days, hours, minutes, seconds,
milliseconds, microseconds, nanoseconds) is simply the whole
duration re-expressed in that one unit alone, truncated towards zero
– not a calendar-style “the months-of-year part” breakdown. E.g. for
duration({years: 1, months: 4, ...}) (16 total months), d.years is
16 / 12 = 1 and d.months is 16 itself, not 4. Verified against
every field in Temporal5’s “accessors for duration” scenario. The
*OfX fields (monthsOfYear, secondsOfMinute, …) are each the
same computation’s remainder instead of its quotient – literally
“what d.<prop> would be, mod the next unit up”.
seconds/nanos are stored the same way real Cypher’s own Duration
stores them (mirroring Java’s Duration): seconds carries the whole
sign, nanos is always non-negative (0..999_999_999) – see
PropertyValue::Duration’s own docs. Component accessors must read
off these two raw fields directly, not recombine them into one
signed total and re-split – that would silently reintroduce a
negative nanos (-23H-59M-59.9S‘s stored form is seconds: -86400, nanos: 100_000_000; re-splitting -86399.9s via truncating division
gives the wrong seconds: -86399, nanosecondsOfSecond: -900_000_000
instead, TCK’s Temporal10 [1]). hours/minutes/seconds (and
their -OfHour/-OfMinute cousins) only ever divide seconds itself
(never touch nanos – a whole hour/minute can’t hide inside a
sub-second remainder); milliseconds/microseconds/nanoseconds
(the fine-grained totals, not -OfSecond splits) are the one place
that legitimately combines both fields, since nanos’ own
always-non-negative convention means simple addition (not total_ns
division-then-truncation) already gives the right signed result.