Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG]+[FIX] Correct 1-hour offset on messages timestamps #124

Open
Box333 opened this issue Dec 7, 2024 · 1 comment
Open

[BUG]+[FIX] Correct 1-hour offset on messages timestamps #124

Box333 opened this issue Dec 7, 2024 · 1 comment
Assignees
Labels
bug Something isn't working enhancement New feature or request

Comments

@Box333
Copy link

Box333 commented Dec 7, 2024

Hi Knugi,

i ve been wondering, why there is a time shift of 1 hour of the messages timestamps. The error is in utility.py:

Instead of:
'APPLE_TIME = datetime.timestamp(datetime(2001, 1, 1))'
you have to use:
APPLE_TIME = datetime.timestamp(datetime(2001, 1, 1, tzinfo=timezone.utc))'

add from datetime import timezone

Why the 1-Hour Difference Happens:

In your calculation (APPLE_TIME), the local time is created based on the system’s time zone, and when you call timestamp(), it converts the local time to UTC. If your system is in a time zone with a 1-hour offset from UTC (e.g., UTC+1 or a daylight-saving adjustment), the timestamp generated will reflect that conversion and the 1-hour shift.

For example, if your system is set to UTC+1, calling timestamp() on datetime(2001, 1, 1) will convert it to UTC. The difference between the time zone (UTC+1) and UTC will cause a 1-hour shift.

If you want to use APPLE_TIME correctly, you should adjust for the time zone by considering the system’s local time zone or ensuring you are always working with UTC time. To ensure consistent results, it’s always best to work with UTC time when dealing with timestamps, or explicitly handle time zone offsets.

you could also use:
APPLE_TIME = datetime(2001, 1, 1, tzinfo=timezone.utc).timestamp()
OR
978307200 + msg.timestamp (978307200 = 31Years)

Let me know, if you need further explanation

@KnugiHK
Copy link
Owner

KnugiHK commented Dec 8, 2024

Hardcoding the timestamp makes sense, as it will always remain constant. This is fixed in 82d2485.

I also implemented automation to apply the timezone based on the OS data in a8bac88. Let me know if you found any issues.

@KnugiHK KnugiHK self-assigned this Dec 8, 2024
@KnugiHK KnugiHK added bug Something isn't working enhancement New feature or request labels Dec 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants