Extend Convert Date epoch calculation to respect timezone via %Z date_format

[ruudharing]

Hi,
Using Robot 'Convert Date' function (in DateTime library) to check the correspondence between timestamp and epoch, both delivered by a device under test (DUT). Problem: the DUT is in another timezone. Moreover, the firmware on the DUT does not even understand timezones, i.e. it deals in "naive time" (timezone unaware).

Say that the naive timestamp is 01/04/2023 09:03:10 and the corresponding naive epoch is 1672822990.0 .
This calculation can be checked by e.g. https://www.epochconverter.com/ -- if it is pretended that the DUT is operating in UTC/GMT (which is effectively what the "naive time" handling pretends to do).

However, Convert Date ${timestamp} epoch exclude_millis=yes date_format=%m/%d/%Y %H:%M:%S
implicitly assumes the timezone of the local machine running Robot, and, if that is not in UTC, it yields another number -- which is off by whatever number of seconds corresponds to the local machine's UTC timezone offset (like 18000 s for my machine in EST = UTC - 05:00).
Note that the local machine's timezone should be irrelevant, since we are not comparing between DUT and local machine. Instead we are trying to check on what the DUT is doing internally, in its own (pretended) timezone.

I tried forcing the issue by adding UTC to the timestamp and %Z to the date_format

    ${timestamp_UTC}=   Set Variable  01/04/2023 09:03:10 UTC
    ${epoch_date2}=     Convert Date  ${timestamp_UTC}  epoch  exclude_millis=yes  date_format=%m/%d/%Y %H:%M:%S %Z

but this fails: the UTC and %Z are ignored and the answer is the same as before: the timestamp is still interpreted as if given in the timezone of the local machine. Request is to make this work.

Note: The Python locale clearly supports the %Z format with both UTC and local TZ abbreviation (like EST for me). If I specify a timezone this machine is not familiar with (like PST) or nonsense (like PxT), I get the appropriate Python ValueError. This indicates to me that the underlying Python, at least, sees the correct date_format on input. But then it ignores the UTC timezone in the subsequent epoch calculation.

Workarounds are, of course, possible. I can obtain the local offset and do some manipulation to get the desired answer.
However, it would be much more elegant to make the %Z work in the date_format, even if it would only accept local timezone and UTC. Thanks!

[ruudharing]

Oops, wrong repo... sorry. Transferred to robotframework/robotframework#4590