This means that if I call AugmentedDiffSource.sequenceToTimestamp(4216952) I get back 2020-09-18T17:27:00Z. If I query overpass for the same augmented diff ID, I get osm elements modified in the range 2020-09-18T17:27:00Z through 2020-09-18T17:28:00Z. According to https://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs#Time_slices_and_numbering, the timestamp should be the end time of the range, so we're off by one.
To fix, we should update the epoch offset in our methods to match the 1347432960 used by Overpass.
This would be a breaking change and may require special consideration by downstream clients in order to to adjust correctly.
The official conversion at https://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs#Time_slices_and_numbering uses the epoch offset of
1347432960and the sequence id refers to the timestamp at the end of the minute.Vectorpipe defines its conversion as https://github.com/geotrellis/vectorpipe/blob/master/src/main/scala/vectorpipe/sources/AugmentedDiffSource.scala#L134 which uses the epoch offset
1347432900.This means that if I call
AugmentedDiffSource.sequenceToTimestamp(4216952)I get back 2020-09-18T17:27:00Z. If I query overpass for the same augmented diff ID, I get osm elements modified in the range 2020-09-18T17:27:00Z through 2020-09-18T17:28:00Z. According to https://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs#Time_slices_and_numbering, the timestamp should be the end time of the range, so we're off by one.To fix, we should update the epoch offset in our methods to match the
1347432960used by Overpass.This would be a breaking change and may require special consideration by downstream clients in order to to adjust correctly.