Converting UTC in utime.localtime giving wrong date

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
Post Reply
User avatar
The Royal We
Posts: 8
Joined: Thu Jan 12, 2017 5:40 pm

Converting UTC in utime.localtime giving wrong date

Post by The Royal We » Tue Mar 21, 2017 5:29 am

I would like to make requests to an API, but one of the required parameters is a date string. My workaround for not having a RTC is to get a timestamp from timezonedb.com and convert it to a string.

My issue is that, when I pass the timestamp through utime.localtime it returns a date 30 years in the future. When I pass the date tuple back through utime.mktime it returns to the proper timestamp. I have confirmed that the timestamp is correct independently.

Why is utime.localtime() converting the date incorrectly? How can I fix that? OR Is there a better way to get the current date and time as a string?

Here is a sample:

Code: Select all

>>> import utime
>>> currently = utime.localtime()
>>> print(currently)
(2000, 1, 1, 0, 20, 8, 5, 1)
>>> utime.mktime(currently)
1208
>>> epoch = 1490014068
>>> utime.localtime(epoch)
(2047, 3, 20, 12, 47, 48, 2, 79)
>>> utime.mktime((2047, 3, 20, 12, 47, 48, 2, 79))
1490014068
Thanks!

Running v1.8.7 on an Adafruit Feather Huzzah

User avatar
Roberthh
Posts: 1569
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Converting UTC in utime.localtime giving wrong date

Post by Roberthh » Tue Mar 21, 2017 6:49 am

Maybe the two instances have a different date for the value of 0. I could not tell immediately. On ESP8266, the time is given as distance to Jan 1, 2000, 0:0:0 I personally use the following two lines in main.py to set the time:

Code: Select all

from ntptime import settime
settime()
That works and returne UTC time then with utime.localtime()

Online
User avatar
dhylands
Posts: 3212
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Converting UTC in utime.localtime giving wrong date

Post by dhylands » Tue Mar 21, 2017 7:11 am

linux uses an epoch of 1976, where micropython uses 2000.

The timestamp you're getting from timezonedb.com will be using the 1976 epoch.

You can get the timestamp for Jan 1, 2000 (in the 1976 epoch) and use that to convert from one timebase to the other.

User avatar
The Royal We
Posts: 8
Joined: Thu Jan 12, 2017 5:40 pm

Re: Converting UTC in utime.localtime giving wrong date

Post by The Royal We » Tue Mar 21, 2017 4:45 pm

Thanks for the replies.

You were on point in that the source of the problem was that the two sources had a different 0 point for their start point. As @dhylands suggested I can take the timestamp of 2000, 01, 01 00:00:00 in the 1976 epoch to convert to one utime.localtime() can use. Since I don't need precise accuracy this will work just fine.

Here is an example:

Code: Select all

>>> import utime
>>> epoch = 1490113703 #Current 1976 epoch timestamp
>>> time_diff = 946684800 #The 1976 epoch timestamp on 2000, 01, 01 00:00:00
>>> utime.localtime(epoch - time_diff) #Passing the difference, 543428903, into localtime to get tuple 
(2017, 3, 21, 16, 28, 23, 1, 80) #March 21, 2017 at 16:28:23 GMT
>>> >>> import utime
However, using ntptime.settime() looks a lot more efficient and I am going to need to try it out too.

Thanks again!

User avatar
cagiva
Posts: 22
Joined: Wed Dec 14, 2016 4:49 pm

Re: Converting UTC in utime.localtime giving wrong date

Post by cagiva » Sat Oct 28, 2017 3:35 am

@The Royal We and @dhylands, thank you both for posting this information. It helped me a lot. I have just one question. "The Royal We" is getting GMT date/time, how did you convert it to PST? Just subtract 7 epoch hours?

User avatar
pythoncoder
Posts: 3539
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Converting UTC in utime.localtime giving wrong date

Post by pythoncoder » Sat Oct 28, 2017 5:10 am

MicroPython does not (yet?) support timezones so yes, you do need to adjust manually. This can be a bit involved for DST (daylight saving time) if your timezone uses it and your application requires it.
Peter Hinch

Post Reply