Convert NTP UTC time to localtime (newlib)

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?

Reply to
pozz
Loading thread data ...

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 to
Clifford Heath

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

formatting link
======================================================
formatting link

Reply to
Dimiter_Popoff

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 to
upsidedown

formatting link
formatting link

There's a variety of tools that manipulate the raw database files.

Don't do that. Timezone rules change a lot more frequently than you'd think.

Theo

Reply to
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 to
Dimiter_Popoff

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 to
Clifford Heath

I remember it from the 1980's. So yeah, new... if you're thinking in geological terms.

Reply to
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 to
Dimiter_Popoff

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

Reply to
Dimiter_Popoff

Am 01.04.2018 um 12:01 schrieb Dimiter_Popoff:

The only thing that's new about that is the "IANA" part. Paul Eggert has been maintaining the actual database in the public domain for a bit over 30 years now.

Reply to
Hans-Bernhard Bröker

POSIX specifies the content of the TZ variable here:

Reply to
Michael Bäuerle

I recently described my approach to calculating DST based on a local clock chip. Parameters that you would feed in would be the generic date of spring forward (for example 3rd sunday of May) and fall back (like first Sunday in November). I am not sure if you were looking for an automated method of adjusting DST based on geographical location, but if you or the user are prepared to set up the generic change dates (keep in mind these can change as happened in the USA 3 or 4 years ago), then perhaps my code could be of some help. See

formatting link

--------------------------------------- Posted through

formatting link

Reply to
antedeluvian

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.