My platform is an NXP MCU Cortex-M3 running an SNTP client on top of lwip TCP/IP stack. I correctly receive current time (seconds from epoch) in UTC. Now I would like to convert it in struct tm *localtime*. There's localtime() function that is what I tried to call. However, as expected, localtime() returns UTC. My C libraries are newlib and I suspect newlib thinks the timezone is UTC without daylight savings. Now the question is: how to configure newlib libraries to use a specific timezone (Italy, in my case) so localtime() works as expected?
Convert NTP UTC time to localtime (newlib)
Started by ●March 30, 2018
Reply by ●March 30, 20182018-03-30
On 31/03/18 02:46, pozz wrote:> My platform is an NXP MCU Cortex-M3 running an SNTP client on top of > lwip TCP/IP stack. > > I correctly receive current time (seconds from epoch) in UTC. Now I > would like to convert it in struct tm *localtime*. > There's localtime() function that is what I tried to call.� However, as > expected, localtime() returns UTC. > > My C libraries are newlib and I suspect newlib thinks the timezone is > UTC without daylight savings. > > Now the question is: how to configure newlib libraries to use a specific > timezone (Italy, in my case) so localtime() works as expected?I can't tell you about newlib, but *nix systems look at the TZ environment variable. Sydney is currently EDT-11, tomorrow EST-10.
Reply by ●March 31, 20182018-03-31
On 31.3.2018 г. 00:46, Clifford Heath wrote:> On 31/03/18 02:46, pozz wrote: >> My platform is an NXP MCU Cortex-M3 running an SNTP client on top of >> lwip TCP/IP stack. >> >> I correctly receive current time (seconds from epoch) in UTC. Now I >> would like to convert it in struct tm *localtime*. >> There's localtime() function that is what I tried to call. However, >> as expected, localtime() returns UTC. >> >> My C libraries are newlib and I suspect newlib thinks the timezone is >> UTC without daylight savings. >> >> Now the question is: how to configure newlib libraries to use a >> specific timezone (Italy, in my case) so localtime() works as expected? > > I can't tell you about newlib, but *nix systems look at the TZ > environment variable. Sydney is currently EDT-11, tomorrow EST-10.Do you (or anyone) know of a decent standardized way to locate timezone offsets as they change for summer time (or whatever)? I remember googling 2-3 years ago and found nothing I'd then call "reasonable" (don't remember at all why and what I did find, if anything). At the moment I consider preparing a static file predicting the timezones for a few years ahead and ship that with the OS as it comes from us. Then dps can look for an update of this file from time to time. Have not done it yet because it looks a bulky thing to put together, will cost me a whole day if not more. Dimiter ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
Reply by ●March 31, 20182018-03-31
On Fri, 30 Mar 2018 17:46:57 +0200, pozz <pozzugno@gmail.com> wrote:>My platform is an NXP MCU Cortex-M3 running an SNTP client on top of >lwip TCP/IP stack. > >I correctly receive current time (seconds from epoch) in UTC. Now I >would like to convert it in struct tm *localtime*. >There's localtime() function that is what I tried to call. However, as >expected, localtime() returns UTC. > >My C libraries are newlib and I suspect newlib thinks the timezone is >UTC without daylight savings. > >Now the question is: how to configure newlib libraries to use a specific >timezone (Italy, in my case) so localtime() works as expected?In MS-DOS you could say SET TZ=EET-2EES-3,M3.5.0/02:00,M10.5.0/03:00 - East European standard time is UTC+2 (EET+2) - East European summer time is UTC+3 (EST+3) - Switch to summer time in March (M3) - In the last week of that month (5) - In sunday (0) - At 02:00 local standard time (00:00 UTC) - Switch to standard time the last sunday in October (M10.5.0) - At 03:00 local summer time (00:00 UTC) For other time zones at least in Europe, adjust the hours to match 00:00 UTC. The date rule applies at least in the EU. Which country belongs to which standard time zone can vary over time. Check the Time Zone Database. Which countries use Summer time varies by country and year. Russia used previously standard/summer time but is now in standard time all year around. Thus Moscow time is all year around UTC+3, the same as East Europe Summer time.
Reply by ●March 31, 20182018-03-31
Dimiter_Popoff <dp@tgi-sci.com> wrote:> Do you (or anyone) know of a decent standardized way to locate timezone > offsets as they change for summer time (or whatever)?https://www.iana.org/time-zones https://en.wikipedia.org/wiki/Tz_database There's a variety of tools that manipulate the raw database files.> At the moment I consider preparing a static file predicting the > timezones for a few years ahead and ship that with the OS as it comes > from us. Then dps can look for an update of this file from time > to time.Don't do that. Timezone rules change a lot more frequently than you'd think. Theo
Reply by ●April 1, 20182018-04-01
On 01.4.2018 г. 01:37, Theo wrote:> Dimiter_Popoff <dp@tgi-sci.com> wrote: >> Do you (or anyone) know of a decent standardized way to locate timezone >> offsets as they change for summer time (or whatever)? > > https://www.iana.org/time-zones > https://en.wikipedia.org/wiki/Tz_database > > There's a variety of tools that manipulate the raw database files. > >> At the moment I consider preparing a static file predicting the >> timezones for a few years ahead and ship that with the OS as it comes >> from us. Then dps can look for an update of this file from time >> to time. > > Don't do that. Timezone rules change a lot more frequently than you'd > think. > > Theo >Thanks, this time zone database is apparently a new thing, don't think I had seen it during my former search. Looks like this is the way to go, I only have to get around to it. Dimiter
Reply by ●April 1, 20182018-04-01
On 31/03/18 23:34, Dimiter_Popoff wrote:> On 31.3.2018 г. 00:46, Clifford Heath wrote: >> I can't tell you about newlib, but *nix systems look at the TZ >> environment variable. Sydney is currently EDT-11, tomorrow EST-10. > Do you (or anyone) know of a decent standardized way to locate timezone > offsets as they change for summer time (or whatever)?If by "locating" you mean not just knowing the timezones, but knowing *where* each timezone applies... you basically can't do that. There are many geographic borders that are timezone boundaries, not just divisions of the 360 degrees of longitude. China alone should span 5 timezones, yet has only one. As has been pointed out, any locality can declare different changeover dates and times, and there are many such changes every year, so you need be able to get an up-to-date timezone file at the very least once per year. It's not possible to predict it in advance. Clifford Heath.
Reply by ●April 1, 20182018-04-01
On 01/04/18 19:46, Dimiter_Popoff wrote:> On 01.4.2018 г. 01:37, Theo wrote: >> Dimiter_Popoff <dp@tgi-sci.com> wrote: >>> Do you (or anyone) know of a decent standardized way to locate timezone >>> offsets as they change for summer time (or whatever)? >> >> https://www.iana.org/time-zones >> https://en.wikipedia.org/wiki/Tz_database >> >> There's a variety of tools that manipulate the raw database files. >> >>> At the moment I consider preparing a static file predicting the >>> timezones for a few years ahead and ship that with the OS as it comes >>> from us. Then dps can look for an update of this file from time >>> to time. >> >> Don't do that. Timezone rules change a lot more frequently than you'd >> think. >> >> Theo >> > > Thanks, this time zone database is apparently a new thingI remember it from the 1980's. So yeah, new... if you're thinking in geological terms.
Reply by ●April 1, 20182018-04-01
On 01.4.2018 г. 12:47, Clifford Heath wrote:> On 31/03/18 23:34, Dimiter_Popoff wrote: >> On 31.3.2018 г. 00:46, Clifford Heath wrote: >>> I can't tell you about newlib, but *nix systems look at the TZ >>> environment variable. Sydney is currently EDT-11, tomorrow EST-10. >> Do you (or anyone) know of a decent standardized way to locate timezone >> offsets as they change for summer time (or whatever)? > If by "locating" you mean not just knowing the timezones, but > knowing *where* each timezone applies... you basically can't > do that. There are many geographic borders that are timezone > boundaries, not just divisions of the 360 degrees of longitude. > China alone should span 5 timezones, yet has only one. > > As has been pointed out, any locality can declare different > changeover dates and times, and there are many such changes > every year, so you need be able to get an up-to-date timezone > file at the very least once per year. It's not possible to > predict it in advance. > > Clifford Heath.Oh no, I am not after anything that omnipotent. I just want my devices to be able to switch between summer time and back as all the phones and laptops etc. do. Setting the timezone you are in once is OK, in fact our volume is low enough so we ship our units with the timezone already set for the respective customer. And that new IANA timezone database seems to be the answer, I'll look into it. Dimiter
Reply by ●April 1, 20182018-04-01
On 01.4.2018 г. 12:56, Clifford Heath wrote:> On 01/04/18 19:46, Dimiter_Popoff wrote: >> On 01.4.2018 г. 01:37, Theo wrote: >>> Dimiter_Popoff <dp@tgi-sci.com> wrote: >>>> Do you (or anyone) know of a decent standardized way to locate timezone >>>> offsets as they change for summer time (or whatever)? >>> >>> https://www.iana.org/time-zones >>> https://en.wikipedia.org/wiki/Tz_database >>> >>> There's a variety of tools that manipulate the raw database files. >>> >>>> At the moment I consider preparing a static file predicting the >>>> timezones for a few years ahead and ship that with the OS as it comes >>>> from us. Then dps can look for an update of this file from time >>>> to time. >>> >>> Don't do that. Timezone rules change a lot more frequently than you'd >>> think. >>> >>> Theo >>> >> >> Thanks, this time zone database is apparently a new thing > > I remember it from the 1980's. So yeah, new... > if you're thinking in geological terms.LOL, may be it is that old and I have overlooked it. It only goes back to 2016 though (after a brief look through their ftp address). Dimiter
