Reasonable numbers in TXT records

[m3047]

Right now, a TXT record looks a lot like this (two examples):

57.161.20.100.in-addr.arpa.rearview.m3047.net. 600 IN TXT "depth=2,first=1681183806.243363,last=1681408935.7175434,count=4,trend=20764.805014878275,update=1681440677.1266115,score=1.989519303716306"
43.166.20.100.in-addr.arpa.rearview.m3047.net. 600 IN TXT "depth=5,first=1680501488.6834428,last=1680501488.6837842,count=2,trend=3.404617309570313e-05,update=1681415738.623454,score=1.690577477672348"

There are two problems with this:

• The floating points are obnoxiously (and unnecessarily) long.
• The second trend value is in scientific notation because it's so small.

Some observations:

• first, last, update are (*nix) datetimes. One second (integer) resolution is fine for historical purposes.
• trend is a number of seconds. Likewise one second (integer) resolution is fine for historical purposes.
• score probably doesn't need more than one decimal point of precision. Three decimal points is plenty of overkill.

I hope this is backwards compatible with whatever you using (outside of RVR itself) to parse TXT records.

I anticipate completing this change sometime in the next few weeks. I'll let it "soak" in the fwm branch for at least a few days, possibly as long as a week.

[m3047]

The update is on the fwm branch and I'm running it locally.

[m3047]

fwm merged to main at 18b384a

• Verified the KNIME workflow still loads the data correctly.
• Verified that the data loads correctly internally after a restart.

Examples:

111.53.16.104.in-addr.arpa.rearview.m3047.net. 600 IN TXT "depth=1,first=1682063117,last=1682063117,count=1,trend=0,update=1682063118,score=0.333"
101.56.16.104.in-addr.arpa.rearview.m3047.net. 600 IN TXT "depth=1,first=1682019224,last=1682019224,count=1,trend=0,update=1682019225,score=0.333"