juha-ylikoski

@pekkaklarck sorry for no reply. We initially fixed this internally by substracting y2037 from the DateTime object and then handling the integer conversion. (with something like `Subtract Time From Date`)...

I guess you are referring to commit id ebbcd9580d1a1a34a048e6dbb2fdd14e274b23e9 (the link was broken). I have installed the version by creating a new python virtual env and installing the robotframework with:...

I can deserialize a timestamp in 2065 with: ```python3 >>> import datetime >>> print(datetime.datetime.utcfromtimestamp(0)+datetime.timedelta(seconds=3000000000)) 2065-01-24 05:20:00 ``` And I tested that also this works: ```python3 >>> import datetime >>> datetime.datetime.utcfromtimestamp(0)+datetime.timedelta(seconds=3000000000)...

I can.

Now the 2040 works but the larger ones do not: ```bash $ cat tc.robot *** Settings *** Library DateTime ***Variables*** ${date1}= Dec 31 14:10:36 2040 GMT ***Test Cases*** 2040 Log...

The conversions seem to now be not crashing, but your addition of additional daylight saving time is breaking it. ```robot *** Settings *** Library DateTime ***Variables*** ${i31_m_1}= Jan 19 03:14:07...

@pekkaklarck do you know in what timezone the CI is configured in? Usually when I've been running servers, I have them in utc time. This could also make the test...

I have encountered the problem with both ways. >think that the problem has to do something with the looping of this library. I have since posting this issue written my...

How I've tried to use this library: 1) I used subscribe keyword to get all messages from one topic for few minutes. This fails about 1/2 of times not returning...

I might have time next weekend to create pr with background looping instead of current looping mechanism. However I do not know how I would validate this will fix this...