Comment 1 Frida Flodin 2024-04-12 10:55:42 CEST

As far as I can tell, Python does not plan to remove utcnow in the foreseeable future [1]. Since utcnow seems widely used, they have not put a deadline for removal. 

[1] https://github.com/python/cpython/issues/103857

Comment 2 Frida Flodin 2024-04-12 12:33:46 CEST

We use utcnow and utcfromtimestamp in tlwebadm status page aswell, I get this in the log:

> /opt/thinlinc/modules/thinlinc/tlwebadm/status.py:556: DeprecationWarning: datetime.datetime.utcfromtimestamp() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.fromtimestamp(timestamp, datetime.UTC).
>   o00o0oOOo0Oo = datetime . datetime . utcfromtimestamp ( data [ OO00OOO ] )
> /opt/thinlinc/modules/thinlinc/tlwebadm/status.py:557: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
>   o0o0Oo00000o = datetime . datetime . utcnow ( ) - o00o0oOOo0Oo

Comment 6 Frida Flodin 2024-04-19 09:37:22 CEST

This should be fixed now. Made sure that tlctl and tlwebadm show the right session age and when agents were last update.

Comment 7 Tobias 2024-04-25 15:53:49 CEST

General
=======
Tested this bug using server builds #3552 (pre-fix) and #3566 (post-fix) on
Fedora 40.

In the pre-fix build, deprecation warnings are indeed showing up in the
tlwebadm log and in the terminal when executing tlctl load. Running the post-fix
build, however, yields no such warnings. The affected time difference is working
as intended with the new changes in place.

Furthermore, tlctl load and tlwebadm status/load previously only grabbed the
'seconds' attribute from the timedelta object which resulted in the time
essentially resetting after 24h. This has been made more robust and they now
properly report the correct time which solves bug 8339 in the process.

Finally, I skimmed through the code in search of some dubious instance of time
deltas with improper time zone usage. While we don't explicitly call for UTC in
most places, we refer to the Unix epoch of 1970 which is time zone
independent. In cases where local time is of interest, this appears to be
handled correctly.

Acceptance criteria
===================
MUST:
> utcnow and utcfromtimestamp must not be used anywhere in our code.
✅ These functions are not used anywhere.

> The behaviour should be the same after the changes.
✅ It is.

SHOULD:
> We should use UTC when calculating time differences.
✅ Time differences are calculated time zone independently.

Conclusion
==========
Things are working as intended and the acceptance criteria are fulfilled.

Closing.