Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #27693 > unrolled thread

Convert NTP UTC time to localtime (newlib)

Back to article view | Back to comp.arch.embedded

Contents

  Convert NTP UTC time to localtime (newlib) pozz <pozzugno@gmail.com> - 2018-03-30 17:46 +0200
    Re: Convert NTP UTC time to localtime (newlib) Clifford Heath <no.spam@please.net> - 2018-03-31 08:46 +1100
      Re: Convert NTP UTC time to localtime (newlib) Dimiter_Popoff <dp@tgi-sci.com> - 2018-03-31 15:34 +0300
        Re: Convert NTP UTC time to localtime (newlib) Theo <theom+news@chiark.greenend.org.uk> - 2018-03-31 23:37 +0100
          Re: Convert NTP UTC time to localtime (newlib) Dimiter_Popoff <dp@tgi-sci.com> - 2018-04-01 12:46 +0300
            Re: Convert NTP UTC time to localtime (newlib) Clifford Heath <no.spam@please.net> - 2018-04-01 19:56 +1000
              Re: Convert NTP UTC time to localtime (newlib) Dimiter_Popoff <dp@tgi-sci.com> - 2018-04-01 13:03 +0300
        Re: Convert NTP UTC time to localtime (newlib) Clifford Heath <no.spam@please.net> - 2018-04-01 19:47 +1000
          Re: Convert NTP UTC time to localtime (newlib) Dimiter_Popoff <dp@tgi-sci.com> - 2018-04-01 13:01 +0300
            Re: Convert NTP UTC time to localtime (newlib) Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-04-01 13:30 +0200
    Re: Convert NTP UTC time to localtime (newlib) upsidedown@downunder.com - 2018-03-31 17:19 +0300
      Re: Convert NTP UTC time to localtime (newlib) Michael Bäuerle <michael.baeuerle@stz-e.de> - 2018-04-03 10:35 +0200
    Re: Convert NTP UTC time to localtime (newlib) "antedeluvian" <63015@EmbeddedRelated> - 2018-04-30 11:18 -0500

#27693 — 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?

[toc] | [next] | [standalone]

#27694

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.

[toc] | [prev] | [next] | [standalone]

#27695

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/

[toc] | [prev] | [next] | [standalone]

#27697

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

[toc] | [prev] | [next] | [standalone]

#27699

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

[toc] | [prev] | [next] | [standalone]

#27701

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.

[toc] | [prev] | [next] | [standalone]

#27703

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

[toc] | [prev] | [next] | [standalone]

#27700

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.

[toc] | [prev] | [next] | [standalone]

#27702

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

[toc] | [prev] | [next] | [standalone]

#27704

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.

[toc] | [prev] | [next] | [standalone]

#27696

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.

[toc] | [prev] | [next] | [standalone]

#27705

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

POSIX specifies the content of the TZ variable here:
<http://pubs.opengroup.org/onlinepubs/9699919799.2008edition/basedefs/V1_chap08.html#tag_08_03>

[toc] | [prev] | [next] | [standalone]

#27736

>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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch.embedded

csiph-web