Hi.
 
It doesn’t take into account the daylight saving time. So, if you know the rules for when the hour changes, you can add that manually to your code by checking the current date and adding one more hour if you are within a certain date. That’s why we then recommend to use the World Time.
 
I’m not sure exactly why you’re getting that error on the code…
Do you know what is the exact line of code that is causing the issue?
 
Regards,
Sara
 
 
 
 

Thanks Sara,
I finally got it to work, HOWEVER, there is something very fragile about the “ntptime()” call.
Here is what I found:
If I do a normal load of the program “10_2_get_date_time_ntp.py” and run it, I will get this error:

MPY: soft reboot
Connection successful!
IP address: 192.168.1.176
Traceback (most recent call last):
File “<stdin>”, line 55, in <module>
File “ntptime.py”, line 1, in settime
File “ntptime.py”, line 1, in time
OSError: [Errno 110] ETIMEDOUT

Line 55 is the “ntptime()” call. Please notice the connection seems to be immediate.
No amount of continual trying to run the code will produce anything other than what you see!
However, if I disconnect the Pico from the USB and plug it in again and then run the program, here is what I get:

MPY: soft reboot
Waiting for Wi-Fi connection…
Waiting for Wi-Fi connection…
Waiting for Wi-Fi connection…
Waiting for Wi-Fi connection…
Waiting for Wi-Fi connection…
Waiting for Wi-Fi connection…
Connection successful!
IP address: 192.168.1.176
Traceback (most recent call last):
File “<stdin>”, line 55, in <module>
File “ntptime.py”, line 1, in settime
File “ntptime.py”, line 1, in time
OSError: [Errno 110] ETIMEDOUT

Notice that the retry count is greater (I changed it from the “10” in the original code to “15”. Sometimes it actually took 10 retries to get a connection, but it only seems to happen after I unplug the Pico and plug it in again!
Here is the Kicker — Just about every time when the Pico has been re-plugged in and the code run, and the multiples connection tries occur, I the get the “OSError: [Errno 110] ETIMEDOUT” and THEN if I very quickly press the RUN button in the Thonny IDE, low and behold — it usually runs!!
It seems I can only get it to run after a CLEAN startup of the Pico AND if I quickly press RUN after I get the timeout error. It is VERY repeatable, given that sequence of events.
I have noticed that if I have Thonny opened and then I unplug and re-plug the Pico, Thonny notices and then when I run the program and get the error, I can quickly re-run and it usually works.
I can’t believe I’m the only one who has experienced this behavior!
I hope someone out there has solved this.
Thanks, Ray
 

Sara,
After some experimenting, I got it to work rather consistently.
I changed “timezone_offset = 2” to “timezone_offset = -4” (Normally -5 when NOT Daylight Savings).
I kept “timezone_offset_s = timezone_offset*3600” as is.
I changed “ntptime.settime()” to:

 try:
   ntptime.settime()
 except Exception as e:
   print(f"An error occurred 1: {e}")
 finally:
   try:
     ntptime.settime()
   except Exception as e:
     print(f"An error occurred 2: {e}")

Here is the ouput:

MPY: soft reboot
Waiting for Wi-Fi connection…
Waiting for Wi-Fi connection…
Waiting for Wi-Fi connection…
Waiting for Wi-Fi connection…
Waiting for Wi-Fi connection…
Waiting for Wi-Fi connection…
Waiting for Wi-Fi connection…
Waiting for Wi-Fi connection…
Waiting for Wi-Fi connection…
Waiting for Wi-Fi connection…
Connection successful!
IP address: 192.168.1.176
An error occurred 1: [Errno 110] ETIMEDOUT
An error occurred 2: [Errno 110] ETIMEDOUT
Epoch Time: 1715707738
Time tuple: (2024, 5, 14, 13, 28, 58, 1, 135)
Current date and time:
Year: 2024
Month: 5
Day: 14
Day of the week: 135
Hour: 13
Minute: 28
Second: 58
Day of the Week: Tuesday
Formatted date: 14-05-2024
Formatted time: 13:28:58

The multiple “Waiting …” lines result from unplugging the Pico and then plugging it in (it loses its IP addr).
This approach also yields BOTH “Errno” messages. When it has its IP, only 1 “Errno” message is printed.
In both cases (1 or 2 “Errno” messages), the “ntptime” call works.
You may also notice the time hour is wrong! It should be 17 (5 PM) EDT.
For some crazy reason, if I run it again, it produces 17 instead of 13!
The hour appears to be wrong only when I get BOTH “Errno” messages!
There is something wrong with the ntptime.py module.
Another of the great mysteries: I searched my entire hard drive and could not find a file named “ntptime.py”!
Where does the interpreter get it from when importing?
This is the kind of problem that places one on the edge of insanity — I’m going to give up — for now!
Thanks, Ray

Hi.
I’m sorry, but I haven’t experienced that kind of issue before.
Neither problems connecting the Pico or running the code. For me, everything runs smoothly.
 
Maybe it’s worth trying to load MicroPython again and then check that you’re installing the right version for your board.
 
Regards,
Sara

Sara,
I believe the problem was I had the MicroPython version for the Pico without the W. I have both Pico boards and I only had the version without the W on the host development system since it was the first Pico board I bought.
When I re-flashed the MicroPython version with the W onto my Pico W board, it worked!
However, there is something I still don’t understand.
You notice that the program we are told in the course to download does NOT have the ntptime call within a try/except block. When I download and run the program without any mods except network credentials and timezone_offset, it FAILS with the error I reported in previous remarks.
The ONLY way I can get it to work is to place the ntptime() call inside 2 try/except blocks with a “finally” clause!
Are you saying you can run the program recommended for downloading in Unit 10.2 of the course WITHOUT placing the ntptime() call inside a try/except block and it works?
If that is the case, then there must be some network timing issue difference between my local network and whatever you use in your lab.
I even tried Unit 10.2 on a new computer which had nothing on it except Windows 11 and it still failed with the try/except blocks!
Ray

“and it still failed with the try/except blocks!” is supposed to be “and it still failed withOUT the try/except blocks!”
Ray

Hi.
I just tested the code and everything is working as it is.
Are you sure you’re running the correct code?
This is the code: https://github.com/RuiSantosdotme/RPi-Pico-W-MicroPython-eBook/blob/main/Code/Module_10/10_2_get_date_time_ntp.py
 
Regards,
Sara

Sara,
I downloaded the code from the link given in the course — it’s the same as you provided in your reply. I compared them line for line just to be sure.
QUESTION: What operating system are you using?
I have spent a considerable amount of time researching the ntptime() call and I could not believe how many people have had trouble with that call!
Nothing I could do, except put the call in a try/except block worked!
It seems odd to me that you would not have had a large number of calls concerning the use of the ntptime() call!
Many of those reporting problems with the call either wrote their own or used another call like the World Time API.
Since I’m using 2 try/except and a ‘finally’ block, the code seems to always work.
I don’t recall ever having it fail after the 3 tries in the try/finally sequence.
At this point, I’m going to give up — it just isn’t worth the time.
I wonder how many people out there have tried this program on Windows and failed but then gave up?
Thanks for your support, Sara,
Ray
 

Hi.
 
Yes.
It works for me without any modifications and without any errors…
Maybe it is related to something on your network. For example, in my case, the Pico always has the same IP address. My router doesn’t change it… I’m not sure if this can interfere with that…
 
It seems you’ll have to use that try and except clauses for your case.
 
Regards,
Sara

Sara,
So far, my experience with “ntptime” is not good. I think you’re correct when you say I’ll have to use the try blocks to make it work.
Even with the try blocks I’m using; it doesn’t always work correctly.
The World Time API is a better choice as best I can presently determine.
I tried your approach by making the IP address static — it still didn’t work reliably!
Thanks for all your help on this issue. We can lay it to rest.
Ray

Ok.
And yes, using WorldTimeAPI is a better choice.
 
I’ll mark this issue as resolved. If you need further help, you just need to open a new question in our forum.
Regards,
Sara