Information about AT+QGPSXTRADATA? command

[AndreySV]

AT+QGPSXTRADATA? returns starting time of the validity period of previously injected data file, but documentation doesn’t mentioned for which timezone is time is.

When XTRA is uninitialized AT+QGPSXTRADATA? returns

$ sudo mmcli -m any --command='AT+QGPSXTRADATA?'
response: '+QGPSXTRADATA: 0,"1980/01/05,19:00:00"'

or some time extracted from injected XTRA data.

$ sudo mmcli -m any --command='AT+QGPSXTRADATA?'
response: '+QGPSXTRADATA: 1440,"2025/10/12,01:00:00"'

Initial date looks odd. I assume it is in some timezone.
How does it correlated to actual time? Is it in UTC or some custom timezone? Which one?

[AndreySV]

I found QMI call, that returns validity information for XTRA data - “Get Predicted Orbits Data Validity” (0x0037).
It returns information in UTC according to this:

loc_api/loc_api_v02/location_service_v02.h

1. Uninitialized xtra data

$ sudo mmcli -m any --command='AT+QGPSXTRADATA?'
response: '+QGPSXTRADATA: 0,"1980/01/05,19:00:00"'



...
[19 окт 2025, 12:46:29] [Debug] [/dev/cdc-wdm0] received generic indication (translated)...
<<<<<< QMUX:
<<<<<<   length  = 32
<<<<<<   flags   = 0x80
<<<<<<   service = "loc"
<<<<<<   client  = 2
<<<<<< QMI:
<<<<<<   flags       = "indication"
<<<<<<   transaction = 1
<<<<<<   tlv_length  = 20
<<<<<<   message     = "Get Predicted Orbits Data Validity" (0x0037)
<<<<<< TLV:
<<<<<<   type       = "Indication Status" (0x01)
<<<<<<   length     = 4
<<<<<<   value      = 00:00:00:00
<<<<<<   translated = success
<<<<<< TLV:
<<<<<<   type       = "Validity Info" (0x10)
<<<<<<   length     = 10
<<<<<<   value      = 80:3D:D5:12:00:00:00:00:00:00
<<<<<<   translated = [ start_utc_timestamp = '315964800' duration_hours = '0' ]

Successfully retrieved validity info: 1980-01-06T00:00:00Z, valid for 0 hours

2. Initialized xtra data

$ sudo mmcli -m any --command='AT+QGPSXTRADATA?'
response: '+QGPSXTRADATA: 1440,"2025/10/12,01:00:00"'


...
[19 окт 2025, 12:37:06] [Debug] [/dev/cdc-wdm0] received generic indication (translated)...
<<<<<< QMUX:
<<<<<<   length  = 32
<<<<<<   flags   = 0x80
<<<<<<   service = "loc"
<<<<<<   client  = 2
<<<<<< QMI:
<<<<<<   flags       = "indication"
<<<<<<   transaction = 1
<<<<<<   tlv_length  = 20
<<<<<<   message     = "Get Predicted Orbits Data Validity" (0x0037)
<<<<<< TLV:
<<<<<<   type       = "Indication Status" (0x01)
<<<<<<   length     = 4
<<<<<<   value      = 00:00:00:00
<<<<<<   translated = success
<<<<<< TLV:
<<<<<<   type       = "Validity Info" (0x10)
<<<<<<   length     = 10
<<<<<<   value      = D0:35:EB:68:00:00:00:00:18:00
<<<<<<   translated = [ start_utc_timestamp = '1760245200' duration_hours = '24' ]

Successfully retrieved validity info: 2025-10-12T05:00:00Z, valid for 24 hours

When I request validity information on EG25-G, I see several hours difference between QMI call result and output of AT+QGPSXTRADATA?. Why is that?

[aghelan_loga]

Dear @AndreySV ,

Thank you for reaching out.

Based on the behavior you captured, AT+QGPSXTRADATA? is reporting the XTRA validity start time in the module’s “local time” (i.e., the same time base/timezone the modem uses for its clock display), while the QMI “Get Predicted Orbits Data Validity (0x0037)” is reporting startTimeInUTC as an absolute UTC epoch timestamp.

That’s why you see a fixed offset of a few hours between them: it’s simply the timezone (and possibly daylight-saving) offset being applied when the AT layer formats the timestamp.

You can see this directly from your two examples:

Uninitialized case: QMI shows 1980-01-06T00:00:00Z, but AT shows 1980/01/05,19:00:00 → that is UTC−5 hours.

Initialized case: QMI shows 2025-10-12T05:00:00Z, but AT shows 2025/10/12,01:00:00 → that is UTC−4 hours (typical DST behavior in some regions).

So the correlation is:
UTC_time = AT_time − (module_timezone_offset)
AT_time = UTC_time + (module_timezone_offset)

If you want AT+QGPSXTRADATA? to match the QMI UTC time, set/keep the modem time in UTC (timezone offset = 0) or disable any automatic timezone update from network, then re-check. As a cross-check, compare the modem’s displayed clock (e.g., the standard AT time readout) against UTC to confirm what offset the modem is currently applying.

Separately (just for context), the QuecOpen GNSS stack supports injecting XTRA data/files into the GNSS engine (e.g., QL_LOC_Xtra_InjectData / QL_LOC_Xtra_InjectFile), and those injected files are what drive the “valid-from + duration” window you’re querying.

Best Regards,
Aghelan