GPS time incorrect

(deleted)

tvr4:
If the time is 11:41 PM EST on 6/29/2020, the gps.time.hour() is returning a value of 3
If I use gps.time.value() it returns 3413300

What are you saying is incorrect ?

Remember a GPS does not display local time, at a particular location in the World, but displays basically UTC time.

Your GPS appears to think its UTC 03:41:33.00

The time a GPS actually shows, when its fully updated, is the time based on 6th Jan 1980 adjusted by the current number of leap seconds (18), so if the number of leap seconds is correct the GPS should show the same time as UTC.

The GPS normally reports time in UTC. You have to adjust this yourself if you want local time.

This may help.

(deleted)

tvr4:
Sorry I was not aware that the GPS time was UTC. That explains why it is different from local time.
I looked at that example and pasted the code into a new ino file.

I am getting this error:
'setTime' was not declared in this scope

THANKS

Did you miss the #include <Time.h>             // Time Library?

(deleted)

(deleted)

If the program compiles, you have the library. There are several places on disk where it might be stored.

If not, in the Arduino IDE, go to tools>manage libraries and install it.

(deleted)

(deleted)

tvr4:
Ran this sketch and there is something wrong with the code. It never finds a GPS signal

I can run the GPS data logger sketch I have and it gets a GPS signal

I suppose that's that then. :frowning:

If only there was some way we could see your code, maybe then we could help?

(deleted)

Please read and follow the directions in the "How to use the forum" post.

(deleted)

tvr4:
I have tried various examples for TonyGPS++ and TimeLib and they work

TonyGPS?

tvr4:
Sorry I was not aware that the GPS time was UTC. That explains why it is different from local time.

Imagine the amount of data the GPS would need to hold, and download on a regular basis, to keep an accurate Geofence of all the various timezones in the world down to an accuracy of a couple of metres.

Imagine the chaos if your GPS was on the border between 3 different time zones and the reported time kept shifting.

tvr4:
I did. Nevermind. I figured it out myself

Dont you think it would be a good idea to reveal to the forum what the problem was ?

It would help anyone who stumbles across this thread in the future.

(deleted)

The time library trivially handles date changes. The unix timestamp encodes both time and date, relative to the epoch chosen.

tvr4:
I don't know an easy way to handle this and really don't want to add a lot more to the code. I will investigate this later though.

Well, Epoch time management has been the easy way to do time manipulation for about 45 years now. It uses 32 bit values representing seconds, so when you compare, add or subtract time, there are never any problems with year month day roll overs or anything like that.

Epoch times are well supported by the Time library, the native time library, and any good RTC library.