Support for RFC 2579 DateAndTime conversion

[SuperQ]

It would be useful to convert RFC 2579 DateAndTime to a unix timestamp.

From SNMPv2-TC:

DateAndTime ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "2d-1d-1d,1d:1d:1d.1d,1a1d:1d"
    STATUS       current
    DESCRIPTION
            "A date-time specification.

            field  octets  contents                  range
            -----  ------  --------                  -----
              1      1-2   year*                     0..65536
              2       3    month                     1..12
              3       4    day                       1..31
              4       5    hour                      0..23
              5       6    minutes                   0..59
              6       7    seconds                   0..60
                           (use 60 for leap-second)
              7       8    deci-seconds              0..9
              8       9    direction from UTC        '+' / '-'
              9      10    hours from UTC*           0..13
             10      11    minutes from UTC          0..59

            * Notes:
            - the value of year is in network-byte order
            - daylight saving time in New Zealand is +13

            For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be
            displayed as:

                             1992-5-26,13:30:15.0,-4:0

            Note that if only local time is known, then timezone
            information (fields 8-10) is not present."
    SYNTAX       OCTET STRING (SIZE (8 | 11))

[brian-brazil]

Note that if there's no timezone, we can't properly convert.

[RichiH]

That's true, but arguably a configuration error by the end user. If they put wrong or incomplete data in other config, we can not do anything but expose it as such.

[brian-brazil]

It's not a configuration error of the user if the device is incapable of outputting timezones.

[RichiH]

While that is true, the common case, in my experience with network devices, is that TZ info is optional, but always supported.

[SuperQ]

The spec says we can basically fake it if the zone is not returned by the device. We can apply something like time.Now().Zone(). Documenting that "Time zones are not always supported" is probably good enough.

[brian-brazil]

We'd have to presume UTC.

[SuperQ]

Yes, you're right, UTC is better. I am doing some testing on my NAS server which returns no zone information, but happens to be set to UTC.