Issue when converting UTC to gps_time

[yanbingyu07]

When converting from UTC to gps_time using this library, I tried to verify against the convertors on following two sites, your results are different. The differences always match the timezone offset (I am in Dallas area). Looked into your source code, I think the _gps_epoch_datetime definition in datetime.py, should specify the timezone of "1980-01-06" as GMT-0, because that's the GPS time starting point.
https://www.andrews.edu/~tzs/timeconv/timedisplay.php
https://gwosc.org/gps/

[davidallen353]

Can you provide a code example? My library should not be impacted by time zones, so I am curious what is going on.

The way I handle leap seconds is very similar to the code example in the first source, so once I have your example I will look for any inconsistency.

[yanbingyu07]

The object datatime(1980,1,6) is interpreted to the timezone of the execution environment.
Suggest to use the tz aware object datetime(1980,1,6, tzinfo=timezone.utc) for the definition of _gps_epoch_datetime.

[vbackeberg]

Same issue here. @davidallen353

The relevant code should be in this line:

gps_time/gps_time/datetime.py

Line 204 in 5ed01b3

week_num = (date_time - _gps_epoch_datetime).days // 7

You can reproduce it instantiating a GPSTime object from timezone-aware datetime object.

GPSTime.from_datetime(datetime.utcnow())

Version 2.8.8

[davidallen353]

I am looking at some of the implications of making the simple change (just adding tzinfo to the GPS epoch). My concern is that old programs may not run the same depending on the local time zone.

If that's the case, I will have to implement a fix that checks if an input datetime object has tzinfo, then processes it accordingly. This would be far from elegant, but it might be the best course of action.

[vbackeberg]

I think that gps_epoch_time is implicitly in the system's local time zone.

That means

1. Fixing gps_epoch_time to UTC
2. Calling datetime.astimezone() on input datetimes without timezones

would be the required measures to fix the issue while staying backwards-compatible.

I have a suspicion that the current implementation might even lead to off-by-one errors for some edge cases where the system's local time is not UTC. gps_epoch_time would be off by some hours in that case potentially resulting in a different number of weeks.

A few tests should give definitive answers on this.

My conclusion is based on this article:
https://blog.ganssle.io/articles/2022/04/naive-local-datetimes.html