Adding handling for system tz not found exception

[AutonomousCat]

Pull Request Type

• Feature addition
• [✓] Bugfix
• Documentation update
• Code refactor
• Tests improvement
• CI/CD pipeline enhancement

Description

It handles a rare exception that was found while testing locally in a Windows 10 environment.

Changes

• A try-except catch for the timestamp.astimezone() function in the return
• Allows fallback handling to UTC, if the system tz isn't found at any time

[AstreaTSS]

I'm somewhat against this idea as by all means, this is a Python and/or operating system bug. It's also a fallback that results in behavior that isn't necessarily consistent with how things usually acts (since UTC is far from being guaranteed as the user's timezone).

Not entirely against it, but still.

[AutonomousCat]

@AstreaTSS The whole library should handle a fallback globally, possibly every connection refresh or initialization? But this fixes the only related bug I've noticed.

[AstreaTSS]

@AstreaTSS The whole library should handle a fallback globally, possibly every connection refresh or initialization? But this fixes the only related bug I've noticed.

Gateway issues are usually machine-dependent, but they're usually down to things we wouldn't consider as bugs and usually happen in normal situations - IE connection being lost briefly.

Meanwhile, the fact this exists suggests the datetime library is getting an edge case on a - specific OS.

That being said, having done more research, what's likely happening here is that the datetime library is being passed a datetime that happens very near to the UNIX epoch. I found issues that suggest that using astimezone() on Windows like this makes things freak out.

Mind you, Discord timestamps shouldn't ever cause this issue, but from looking up the original error that you got, a user's presence can have a timestamp like this that I guess Discord just allows. This solution doesn't actually fix that specific issue - it just works around them.

[AutonomousCat]

@AstreaTSS Well considering Windows users, the Exception is caught every time because Windows has the unix timestamp in milliseconds. Considering this function runs like 5 times a second (in a big server at least), maybe an overall runtime system check is needed?

[AstreaTSS]

@AstreaTSS Well considering Windows users, the Exception is caught every time because Windows has the unix timestamp in milliseconds. Considering this function runs like 5 times a second (in a big server at least), maybe an overall runtime system check is needed?

That's not... quite correct. See my comments on Discord - this issue actually likely has to do with ActivityTimestamp's behavior.

[eightween]

I'm 👎 on this PR, #1626 effectively addresses what I believe to be our issue at hand

[AstreaTSS]

Superceded by #1626.