RTC timestamp = -28800

[lazy-fox-code]

Hello! I'm using the pudding dev board A9G. Why is TIME_GetTime (NULL) or tv.tv_sec timestamp always 28800 behind while TIME_GetLocalTime and TIME_GetRtcTIme return correct date and time? An example with traccar (demo / demo_gps_tracker.c) sends data to the timestamp as -28800. It would be nice to see an example of TIME_SetRtcTime. As a result, I plan to make a GPS time correction.

/**
 * s: 1597918742
 * gmt:  Thu, 20 Aug 2020 10:19:02 GMT
 * localtime: 20.08.2020, 13:19:02
 **/

void TestTime1()
{    
    TIME_System_t localTime;
    TIME_GetLocalTime(&localTime);
    Trace(1,"localtime:%d-%d-%d %02d:%02d:%02d",
    localTime.year,localTime.month,localTime.day,localTime.hour,localTime.minute,localTime.second);
    //localtime:2020-8-20 13:19:02  === correct local time
}

void TestTime2()
{
    RTC_Time_t time;
    TIME_GetRtcTIme(&time); 
    Trace(2,"gmt  time:%d-%d-%d %d:%d:%d +%d",
    time.year,time.month,time.day,time.hour,time.minute,time.second,time.timeZone);
    //gmt  time:2020-8-20 10:19:2 +3 === correct gmt time
}

void TestTime3()
{ 
    uint32_t time = TIME_GetTime(NULL);
    Trace(3,"timestamp:%d",time); //1597889942 === Thu, 20 Aug 2020 02:19:02 GMT (incorrect -28800)

    struct timeval tv;
    gettimeofday(&tv,NULL);
    int sec = tv.tv_sec;
    Trace(3,"timestamp:%d",sec); //1597889942 === Thu, 20 Aug 2020 02:19:02 GMT (incorrect -28800)

    sec += 28800;
    Trace(3,"timestamp:%d",sec); //1597918742 === Thu, 20 Aug 2020 10:19:02 GMT ( ? )
}

[ZakKemble]

Have you tried using TIME_GetTimeZone() / TIME_SetTimeZone()? Maybe it defaults to China, which is +8 hours (28800), kinda like the offset you're seeing here. I also don't think TIME_GetTime() is supposed to take any parameters, maybe remove the NULL.

[lazy-fox-code]

What parameters should be passed to TIME_GetTimeZone () / TIME_SetTimeZone ()? Probably China, which is +8 hours (28800). Is it possible to find out what parameters for the GPRS_C_SDK functions need to be send? I thought the timezone is only in RTC_Time_t, by the way it is displayed correctly (// gmt time: 2020-8-20 10: 19: 2 +3) Unix time is always Greenwich Mean Time. This is the number of seconds from 01/01/1970 00:00:00 GMT. Where does the offset 28800 come from, unless, of course, China does not have its own greenwich? Calling TIME_GetTime () without parameters results in compilation errors:

src/demo_time.c: In function 'TestTime3':
src/demo_time.c:39: error: too few arguments to function 'g_InterfaceVtbl->time'
...

[ZakKemble]

In include/sdk_init.h is looks like the time zone functions take an 8-bit signed integer, which I would guess is the hour offset, so try 8.

The RTC time is set when the module connects to the GSM network and the timezone might also be provided, however not all mobile networks provide the time. The A9G SDK has many bugs and quirks, and a lot of undocumented and unfinished things. The offset 28800 is 8 hours, which is the timezone offset of China from GMT. TIME_GetTime() and gettimeofday() might be using a different system than TIME_GetRtcTIme() and TIME_GetLocalTime() when it comes to what timezone to use, maybe the former use the timezone set by TIME_SetTimeZone() while the latter uses the network timezone.

[lazy-fox-code]

Thanks for the answers. It is clear that the RDA8955 and RTC watches are different stones that they probably tried to synchronize.

However, I assumed that timestamp is independent of timezone. My time zone is +3, and TIME_GetTimeZone () returns 12. When I try to change the TIME_SetTimeZone(), - TIME_GetRtcTIme() times do not change (since they are in GMT), but TIME_GetLocalTime () changes. I do not use time in the form of "Human readable time". For now, only correct GMT is important to me.