GPIO Digital Interrupts using CDev report incorrect timestamps

[CrazyIvan359]

Describe the bug

On OrangePi Zero LTS running Armbian, CDev GPIO interrupt events are reporting timestamps representing system uptime in nanoseconds, instead of epoch nanoseconds. This results in MQTTany thinking that the debounce period has already elapsed and the debounce routine returns immediately. While this does not stop interrupts from working, it does render the debounce setting meaningless.

Expected behavior

Current epoch nanoseconds is on the order of 1.6×10¹⁸ (1,600,000,000,000,000,000).

Environment

• MQTTany version: v0.12.0 and up
• Platform: OrangePi Zero LTS running Armbian 20.08.2 (5.8.6-sunxi)

Logs

Example from OrangePi with incorrect timestamp:

[TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO00 with timestamp 1212347.025238s

Example from RPi3B+ with correct epoch timestamp with microsecond precision:

[TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO09 with timestamp 1608487231.162014s