devices:history flags before/after issues

[sun2sirius]

Describe the bug
Neither --before nor --after flags take the epoch timestamp in milliseconds as it is stated in the documentation. The -B or --before flag works correctly with ISO time string, but not with the epoch timestamp representing the same time. Additionally, the -A or --after does not work correctly at all. I want to read the new device events so I save the timestamp value of the last event and put it on the command line like so: --after= --limit=1000 to get the last event and all new events after it. What I get is a 1000 events that go way before the value that I specified. If I have no new events, I would expect only the last one returned, as documentation says "return events newer than or equal to this timestamp".

To Reproduce
Steps to reproduce the behavior:

1. Get a device with a bunch of events, dump 20 last ones with "smartthings devices:history [ID]" command
2. Note the timestamp of the last event, e.g. time: '2023-11-17T22:49:14.000+00:00' and its epoch: 1700261354823.
3. Run "smartthings devices:history [ID] --after=1700261354823 --limit=1000" - see output of 1000 events
4. Make the value 2700261354823 very far in the future - still get 1000 events.
5. Run "smartthings devices:history [ID] --after=2023-11-17T22:49:14.000+00:00 --limit=1000" - see output of 1000 events
6. Increase the time only 1 sec - the output is empty.

Expected behavior

1. In step 3 above I expect to see only one event returned that corresponds to the last event's timestamp. As per documentation, the last event is inclusive. The flags must accept integer epoch time in milliseconds as per documentation.
2. In step 5, I expect to see the same result as in step 3.

Actual behavior

1. Neither --after nor --before flags accept the integer epoch timestamps.
2. The --after flag does not filter the events after the specified value, it returns all.

Additional context
I initially used an older version of smartthings, but then updated to the latest: @smartthings/cli/1.8.1 win32-x64 node-v18.5.0 - seeing the same behavior.