>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 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
https://www.eeweb.com/profile/aubrey-kagan/articles/correcting-for-daylight-savings-time
---------------------------------------
Posted through http://www.EmbeddedRelated.com
Reply by ●April 3, 20182018-04-03
upsidedown@downunder.com wrote:
> On Fri, 30 Mar 2018 17:46:57 +0200, pozz <pozzugno@gmail.com> wrote:
> >
> > [...]
> > 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
Reply by Hans-Bernhard Bröker●April 1, 20182018-04-01
Am 01.04.2018 um 12:01 schrieb Dimiter_Popoff:
> And that new IANA timezone database seems to be the answer, I'll
> look into it.
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 by Dimiter_Popoff●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
Reply by Dimiter_Popoff●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 Clifford Heath●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 thing
I remember it from the 1980's. So yeah, new...
if you're thinking in geological terms.
Reply by Clifford Heath●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 Dimiter_Popoff●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 Theo●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)?
> 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 ●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.