adam/LoRa_APRS_iGate
1
0 Fork 0
mirror of https://github.com/richonguzman/LoRa_APRS_iGate.git synced 2026-11-03 12:12:20 +01:00
Code Issues 55 Packages Projects Releases Wiki Activity

Change Request: GMT Time Correction Option #193

New Issue
Open
opened 2026-10-05 05:47:38 +02:00 by adam · 9 comments
adam commented 2026-10-05 05:47:38 +02:00
Owner
Copy link
Copy source

Hi,
In another project, the POSIX time zone database is used, which simplifies the switch to daylight saving time in the summer and the return to standard time in the winter. Since most countries still use this system, would it be possible to arrange for this adjustment, along with adding the time server source address (IP or hostname)?

Hi, In another project, the POSIX time zone database is used, which simplifies the switch to daylight saving time in the summer and the return to standard time in the winter. Since most countries still use this system, would it be possible to arrange for this adjustment, along with adding the time server source address (IP or hostname)? <!-- github-sync-id:2987548120 -->
adam commented 2026-10-05 05:47:39 +02:00
Author
Owner
Copy link
Copy source

Hi,
Can you explain the 3 topics a little more?

This proposed idea is to have "auto" change for time zone data in each season?

And the other two?

Hi, Can you explain the 3 topics a little more? This proposed idea is to have "auto" change for time zone data in each season? And the other two? <!-- github-comment-id:2795979741 -->
adam commented 2026-10-05 05:47:40 +02:00
Author
Owner
Copy link
Copy source

Hi,
Yes, the time does change—for example, from CET to CEST during the summer. Information related to the POSIX time zone data can be found here:
https://github.com/nayarsystems/posix_tz_db/blob/master/zones.csv

The second point is to have an option to add a time server to synchronize the time, using an IP address or hostname such as es.pool.ntp.org, for example.

This idea is already implemented in the Meshtastic project, and perhaps some parts of their code could be used as inspiration. I'm not a developer—just thinking it might be possible.
Here is the relevant configuration section:
https://meshtastic.org/docs/configuration/radio/network/#ntp-server

There is no 3 ;)

Hi, Yes, the time does change—for example, from CET to CEST during the summer. Information related to the POSIX time zone data can be found here: https://github.com/nayarsystems/posix_tz_db/blob/master/zones.csv The second point is to have an option to add a time server to synchronize the time, using an IP address or hostname such as es.pool.ntp.org, for example. This idea is already implemented in the Meshtastic project, and perhaps some parts of their code could be used as inspiration. I'm not a developer—just thinking it might be possible. Here is the relevant configuration section: https://meshtastic.org/docs/configuration/radio/network/#ntp-server There is no 3 ;) <!-- github-comment-id:2796012433 -->
adam commented 2026-10-05 05:47:40 +02:00
Author
Owner
Copy link
Copy source

Will check about the changing time zone (does this take care of some countries changing outside the normal change date (sooner or later)?)??

As for NTP, this is already implemented in the code and showed ok the Rx received Packets on the WebUi

Will check about the changing time zone (does this take care of some countries changing outside the normal change date (sooner or later)?)?? As for NTP, this is already implemented in the code and showed ok the Rx received Packets on the WebUi <!-- github-comment-id:2796030632 -->
adam commented 2026-10-05 05:47:41 +02:00
Author
Owner
Copy link
Copy source

Based on my experience with countries like Egypt, the time zone data has occasionally changed during Ramadan. In Europe, for example in Bulgaria where I'm from, the switch between EET and EEST happens at fixed times—on the last Sunday of March and October at 3 AM. I believe it's the same in Central Europe as well.

Based on my experience with countries like Egypt, the time zone data has occasionally changed during Ramadan. In Europe, for example in Bulgaria where I'm from, the switch between EET and EEST happens at fixed times—on the last Sunday of March and October at 3 AM. I believe it's the same in Central Europe as well. <!-- github-comment-id:2796059384 -->
adam commented 2026-10-05 05:47:42 +02:00
Author
Owner
Copy link
Copy source

and here in Arizona USA, we don't participate in the ritual of changing our clocks. %^) So, whatever method might be implemented would also need to accommodate that.

and here in Arizona USA, we don't participate in the ritual of changing our clocks. %^) So, whatever method might be implemented would also need to accommodate that. <!-- github-comment-id:2797712904 -->
adam commented 2026-10-05 05:47:42 +02:00
Author
Owner
Copy link
Copy source

The idea is to set a proper timezone, such as Europe/Paris, US/Arizona, or any other relevant timezone. Additionally, once the correct timezone is set, the system should synchronize time with a local time server, such as 0.arizona.pool.ntp.org.

This will automatically sync the date and time of the gateway when the module is connected to the Internet.

In short, the Time Zone parameter ensures the correct local time. If there is a time shift, the timezone adjusts the date accordingly. If there is no shift, no action is required. In case a leap second is declared for the current year, the Time Zone (TZ) handles it on the specified day. The time server provides the correct signal to synchronize the clock based on world time servers.

This is valid only for the Gates without GPS which is cheaper then installing GPS module on a fixed location.

The idea is to set a proper timezone, such as Europe/Paris, US/Arizona, or any other relevant timezone. Additionally, once the correct timezone is set, the system should synchronize time with a local time server, such as 0.arizona.pool.ntp.org. This will automatically sync the date and time of the gateway when the module is connected to the Internet. In short, the Time Zone parameter ensures the correct local time. If there is a time shift, the timezone adjusts the date accordingly. If there is no shift, no action is required. In case a leap second is declared for the current year, the Time Zone (TZ) handles it on the specified day. The time server provides the correct signal to synchronize the clock based on world time servers. This is valid only for the Gates without GPS which is cheaper then installing GPS module on a fixed location. <!-- github-comment-id:2801263604 -->
adam commented 2026-10-05 05:47:43 +02:00
Author
Owner
Copy link
Copy source

this could be solved by using ntp with known timezones defined, right? or are all ntp servers UTC defined?

this could be solved by using ntp with known timezones defined, right? or are all ntp servers UTC defined? <!-- github-comment-id:2801489985 -->
adam commented 2026-10-05 05:47:44 +02:00
Author
Owner
Copy link
Copy source

Hi Ricardo,

No, I think the time server did not provide TZ data information - just the sync protocol. TZ data has been provided as a Linux package containing TZ information and handling the switching of daylight saving time.

Hi Ricardo, No, I think the time server did not provide TZ data information - just the sync protocol. TZ data has been provided as a Linux package containing TZ information and handling the switching of daylight saving time. <!-- github-comment-id:2810131832 -->
adam commented 2026-10-05 05:47:44 +02:00
Author
Owner
Copy link
Copy source

@richonguzman, please look at this project to get the tool:
https://github.com/ropg/ezTime?tab=readme-ov-file#timezones-1

@richonguzman, please look at this project to get the tool: [https://github.com/ropg/ezTime?tab=readme-ov-file#timezones-1](url) <!-- github-comment-id:2993647473 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/LoRa_APRS_iGate#193