Error parsing "verified" time.

[drallgood]

I'm getting an error when fetching zones: decode: parse time: parsing time "2020-04-07 01:55:32.993931247 +0000 UTC m=+725.120303578": extra text: " m=+725.120303578"

Seems to me it doesn't handle the rather weird time entry Hetzner returns (also doesn't seem to be documented anywhere in their API docs.. at least I couldn't find it anywhere)

From the JSON:

...
"verified": "2020-04-07 01:55:32.993931247 +0000 UTC m=+725.120303578",
...

[acim]

I am not sure what to do about this. We have either to contact Hetzner and find out how to parse it or simply declare this field as string and stop parsing it as time. If we just drop a piece of string, parsed time may be wrong anyways so why should we parse it at all?

[drallgood]

The monotonic time isn't even supposed to be used anywhere. It's actually mostly for debugging purposes. So the recommended way (even from the Go community) is to simply drop it. They recommend never including it at all actually. I bet Hetzner just forgot about this. it seems a defunct field anyway. Not even filled on newer domains

My recommendation: Drop it.

[marvinruder]

In response to a support ticket I raised, I received the following response from a Hetzner representative:

Re: [Ticket#2024010203025267] dns panel support form

Dear Mr. Ruder,

as already pointed out in the issue that you posted, this is the monotonic time offset. You can just drop this when parsing this field.

I am unsure as to why this is included. To investigate this further, I will forward this ticket to the responsible department.

I would suggest to wait for a few more days, maybe they will (silently) drop the monotonic time offset from their API responses, but if not, we now have confirmation that discarding it as proposed in #8 is a safe option.

[acim]

Great, if you guys agree, I would wait for Hetzner few days more and if they don't fix it let's just merge this. However, if this merge is urgent for anyone, I will just merge it, just let me know.

[marvinruder]

In an update to the support ticket I raised Hetzner claims to have fixed the issue:

Dear client,

thanks for reporting the issue. Indeed there had been an inconsistency in the timestamp format with some of the older zones which has now been fixed.

Otherwise - the "m=+" suffix could be ignored. It's a reference to the Monotonic Clock.

@drallgood Could you check whether the API now returns well-formatted time stamps for the zones you had issues with earlier?

[drallgood]

@marvinruder Indeed they fixed it. Now it doesn't return a verified value anymore. So this works now

Guess we can close this issue

Thanks for your help!

[acim]

Great, guys, thank you very much.