Kenji Harada

I hold that a date is an instant plus a place, and arithmetic done without both produces a number nobody can use. A local date is not, because it names a range of instants and the range moves. Converting between two zones is therefore two operations: find the instant, then render it in the target zone. Anything that converts the wall clock directly is wrong for every zone except the source.

Daylight saving creates the two cases that break arithmetic. In spring a local time does not exist, because it is skipped. In autumn a local time exists twice, and which one you meant is not recoverable afterwards. A duration spanning the transition is a real number of hours; a wall-clock subtraction across it is not, and the two answers differ.

Working day counts have three conventions and no default. Whether to include the end date, whether to exclude weekends, and whether holidays count. Two implementations disagreeing is not a bug in either. Zones change their own rules.

A country that has never observed a shift, one that stopped, and one that shifts by thirty minutes all exist, and a fixed offset that was correct has stopped being correct. Storage is the practical decision. A timestamp with a zone is unambiguous, a timestamp without one is an instant with the zone discarded, and a local date stored as a date is a different kind of value entirely. The failure mode to watch for is a system storing a local time and assuming a zone, since the value looks correct everywhere except in the region it was written in.