OK, that’s what I was trying to get to the bottom of here:
If you tag start_date=1783
on something, the renderer interprets that as January 1, 1783, at the earliest. However, if you tag end_date=1783
on something, the renderer interprets it as the stroke of midnight at the end of December 31, 1783, as the latest possible end date. And the time slider on the homepage always assumes noon on the selected date, just to be on the safe side.
Therefore, I think the approach you’re describing may have the opposite effect and meaning than what you expect. Keeping the end and start dates a year apart means the changeover took place on January 1. Similarly, if two successive features have day-precision dates, keeping the dates one day apart means the changeover took place at the stroke of midnight. A renderer cannot choose to infer otherwise.
Right, so if you were to tag two successive features with end_date=1784
and start_date=1784
, they’d appear to coexist for an entire year – the year during which we’re unsure which one exists. While this may not look very intuitive, it’s more correct than tagging an EDTF date that contradicts the basic date. The best way to keep them from coexisting is to determine more precise dates.
With the recent changes to boundaries, the renderer recognizes that the end_date=1783
of one feature and the start_date=1784
of a coincident, identically named feature represent a continuous series and conflates the two boundaries’ common edges together. This also works with end_date=1784
and start_date=1784
. So the issue of overlapping features no longer affects boundaries as badly as before.
If you must keep two features one date apart because of a midnight changeover, you can use EDTF tags to affirm this fact:
end_date=1925-04-13
end_date:edtf=1925-04-13T24:00
start_date=1925-04-14
start_date:edtf=1925-04-14T00:00
However, this is probably overkill in most cases, since it’s the default interpretation. I’ve only taken this approach for a couple of time zone boundaries that changed over at midnight, since hour-level precision is important for those boundaries.
Conversely, if you must keep two successive features from coexisting, you could use a less precise set of EDTF dates.
end_date=1784-06-30
end_date:edtf=1784
start_date=1784-07-01
start_date:edtf=1784
Personally, I would only add that additional detail if I have some hunch that the changeover happened mid-year. Otherwise, arbitrary fudge factors like this will only give us headaches down the line as users come to expect micromapping and we have to verify these dates.