Issue 2204 - inaccurate message stats due to nonexistant UTC to local changes

[alexjanousekGSA]

This is for issue: #2204
Related to PR - 2314

Changes

• Added support for passing a timezone parameter to /service/{id}/statistics/{start}/{days} to properly adjust dates when querying stats.
• Default behavior remains the same (UTC) if no timezone is provided.
• Refactored date calculations for better readability and accuracy, removing the old >= 19 check.
• Updated methods to properly convert timestamps and return data in the requested timezone.
• Added and improved test coverage, including edge cases for daylight savings, timezones and large data queries.

[terrazoon]

I don't think we should be using pytz. It alternates between being stable and generating flaky weirdness, depending on the upgrade.

[terrazoon]

we have removed pytz in api when making changes so this would be putting it back.

[terrazoon]

I don't think there should be any changes on the API side. It is the job of the front end to pass UTC time to the backend and convert the backend's UTC time to whatever it needs on the front end.

We do not want to do time conversions on the back end because it adds a lot of complexity and generates defects. DB time is always UTC, backend expects to receive UTC, backend sends UTC. Front end does all conversions because only front end knows the local time, etc.