It would appear that the UPS can report dates such as January 2, 2006 as 1/2/2006 or 2/1/2006, and we have no way of determining which is correct at the moment. Perhaps it's a good idea to suggest some configuration setting, or perhaps there's a way to always work this out based on other information in the request.

After install exporter and activate him, problem with time. In log:
apcupsd-exporter[31009]: 2021/11/18 15:34:21 failed collecting UPS metrics: invalid time duration

rpm -qa | grep apc
apcupsd-3.14.14-18.el7.x86_64

part of result command apcaccess status
BATTDATE : 11/14/2019
NOMOUTV : 230 Volts
FIRMWARE : UPS 10.1 (ID20)
END APC : 2021-11-18 15:51:01 +0300

Apparently MANDATE can also be in a 03/06/09 format in addition to the normal Y-M-D format.

Example in the documentation: http://www.apcupsd.org/manual/manual.html#apcupsd-network-monitoring-cgi-programs

The prometheus exporter fails on my system with this error:
parsing time "03/06/09" as "2006-01-02": cannot parse "6/09" as "2006"
with a MANDATE of 03/06/09.

I have just realized (unfortunately before submitting merge request #1) that the fields XONBATT and XOFFBAT are not always set to a date value. If no transfers to or from battery have happened since apcupsd started, the fields have the value "N/A".
In this case, parsing the value as date fails, causing the whole call to client.Status to fail.

I see two possible ways to fix this:

• Handle the special case of "N/A" by returning nil from status.parseKVTime.
• Let status.parseKVTime fail, but changeclient.Status to continue the loop even if one parse method fails (but log a warning message so the error isn't completely swallowed).

I think I'd prefer the second variant. Currently one single problematic value leads to no status being returned at all. I think it might be better to just have the one unparseable field set to nil but still get all the other values that could be parsed.

@mdlayher I'll gladly implement the fix and submit a new merge request, but I'd like to hear your preference first.

Hello,

Currently in status.go, we have this bit of code, which parses the ALARMDEL value:

case keyAlarmDel:
		// No alarm delay configured.
		if v == "No alarm" {
			break
		}

s.AlarmDel, err = parse()

this accounts for the ALARMDEL having a value of "No alarm". Otherwise, it parses it as a time.Duration. However, this won't always work because there are two other possible non-duration values, per the apcupsd library's source (apcstatus.c):

case 'T':
         s_write(ups, "ALARMDEL : 30 Seconds\n");
         break;
      case 'L':
         s_write(ups, "ALARMDEL : Low Battery\n");
         break;
      case 'N':
         s_write(ups, "ALARMDEL : No alarm\n");
         break;
      case '0':
         s_write(ups, "ALARMDEL : 5 Seconds\n");
         break;
      default:
         s_write(ups, "ALARMDEL : Always\n");
         break;
      }

So, the two that aren't handled currently are 'Always' and 'Low Battery', with 'Always' meaning that alarms should sound immediately and continuously upon power fail, and 'Low Battery' meaning that the alarm should sound only after power fails and battery becomes low. (source).

So I guess 'Always' could be converted to just a '0' duration, but 'Low Battery' is unclear. So it seems like we'd either need to change the status.AlarmDel value to a string, or would have to come up with some duration number for 'Low Battery'?

Let me know what makes sense and I could test it out and make a PR. This is currently causing errors in a Telegraf plugin (influxdata/telegraf#8521).