NTP and timezones


We're developing an application based on Syngergy S5D9 and SSP 1.7.5 and I'm struggling to implement a working "localized" NTP-based RTC.

I'm using the internal RTC (with external back-up power) to keep the UTC time synced with an NTP sever, but I can't figure out a way to add timezone management (with proper DST handling) using built-in/POSIX function.


On another platform we've succesfully used something like

setenv("TZ", "CET-1CEST,M3.5.0/2,M10.5.0/3", 1);

For what I understand this becames the following code in the synergy platform

extern char **environ;

static char *my_env[] = {"TZ", NULL};
static const char posixTz_default[] = "CET-1CEST,M3.5.0/2,M10.5.0/3";

environ = my_env;
_setenv_r(_REENT, "TZ", posixTz_default, 1);


However this is not quite working at all. Got different times between threads when using gettimeofday() and the time zone is totally wrong (ssems like it's applying a -2h offset instead of +2).

Any guess on what I'm doing wrong?




  • Out of curiosity I've tried to change the TZ value to the following:


    Funny thing is that I still have the erratic behaviour (different time reported across different threads, wrong time), but it now seems to offset the UTC time in the correct "direction".

    But that's not how it's supposed to work, as explained here

  • In reply to apiesse:

    If you are using the GCC toolchain woth newlib, I suspect you will have to implement some of the syscalls :-


    to support getting and setting environment variables.
  • In reply to Jeremy:

    Thanks for the reply Jeremy.

    Yes, we're using GCC. So I would have to implement getenv, setenv and tzset to have a minimal working system?
    No luck using _setenv_r and _tzset_r which seems to be present looking at the library headers?


  • In reply to apiesse:

    No, the syscalls are listed here :-

  • In reply to Jeremy:

    Ok, understood.

    Assuming I'm taking a shortcut not implementing the setenv() methond (I just need to modify how my_env is initialized in the example from the first post), I just need to find a working implementation or implement tzset() myself.

    If I do this, will my tzset() be called by localtime()/localtime_r()?


  • In reply to apiesse:

    By default newlib is configured with --specs=rdimon.specs in a Synergy project :-


    This means the syscalls are configured to make semi-hosted calls (newlib\libgloss\arm\syscalls.c in the source for newlib ) by default _gettimeofday() is :-

    If you specify --specs=nosys.specs to make sure no semi-hosted syscalls are used:-



    Then the libnosys _gettimeofday() (src\newlib\libgloss\libnosys\gettod.c) is just a stub :-



    So you will need to provide your own function _gettimeofday(), and set --specs=nosys.specs so that no semihosted syscalls are used, as semihosted syscalls will not work when the debugger is not attached.

  • In reply to Jeremy:

    Thanks Jeremy, this cleared my doubt.

    We're altready provided our own gettimeofday which attachs to the internal RTC. I'll just need to implement the tzset() function and use the timezonedata when extracting the time from the RTC.
  • In reply to apiesse:

    You shouldn't have to implement tzset(), as it is already provided in newlib. There are various locks that might be required (e.g. malloc, environment, timezone) in an RTOS environment. See the attached project that I have have put together to investigate.



  • In reply to Jeremy:

    I assumed tzset() was to be implemented because when I tested it my code hanged.
    Didn't realized I was missing locks implementation. will give the test project a try and let you know.

    For the time being, many thanks Jeremy.



    EDIT: this is working as expected!!