timestamt and unix time don't match

[mrtdlv]

Hey, I use this library and wehen I set the time of the RTC ds3231 to the current time (UTC time zone) and afterwards ask for timestamp.hour()(minute()/seconds() and the unixtime() the unix time is offset compared to hours, minutes by 2 hours can it be that the ds3231 can be set to a specific time zone and thereby gives me this offset? thanks

[awickert]

@mrtdlv Thanks for this. Now, nearly two years later, could you provide some code to reproduce this issue?

The DS3231 should know just one time zone, so this is strange.

[IowaDave]

Hello @mrtdlv , I hope I can help a little with your question.

May I begin by responding to your conjecture about time zone information being set somehow in a DS3231 or a DateTime object? How nice it might be. Alas, neither the DS3231 nor the DateTime class incorporate any information about time zone or Daylight Savings Time.

I realize some time has passed since you posted this issue. Recently, in late summer 2022, there has been some further work done on using Unix-style timestamps with this Library.

• Recent PRs have addressed some consistency issues across different hardware platforms, e.g., AVR and ESP826.
• Also, attention was given to consistency of results between the setEpoch() method of the DS3231 class and the unixtime() method of the DateTime class.

You could help us out, if you choose, by downloading the current library and testing it. Use the Zip archive method to get the most recent work.

I don't believe I have enough information to picture the experience you describe , at least not accurately enough to gauge what happened to you.

I was able to reproduce an experience similar to the one you describe. I obtained a Unix-style timestamp by entering a certain date and time into a web page that converts such information into Unix timestamps. When I put the converted timestamp into a DS3231, using setEpoch(), the time information on the clock differed from my inputs to the web page by a couple of hours, exactly.

Eventually I realized the web page was performing a time zone adjustment by guessing my local time zone based on my IP address. It then added some hours to calculate an equivalent GMT time. The timestamp it gave me was for that different GMT time, not for the date and time values I typed in.

My solution was to adjust the web page inputs until the GMT Time equivalent matched the date, hour, minutes and seconds I wanted to set. When I used the resulting timestamp with setEpoch() the clock settings matched my expectation.

In other words, the DS3231 (and the DateTime class) treat Unix-style timestamps as if they were for the GMT time zone.

Lesson I learned: the program writer bears the responsibility to supply the DS3231 and DateTime class objects with sensible time values that suit the purposes of the program.

I'm going to think about your questions a bit longer. If you have any further thoughts to share please post them here. Thanks again for reaching out with your questions.

[IowaDave]

@awickert @mrtdlv I am changing the label on this Issue to "more-info-needed" for the following reasons:

• Recent PRs have addressed certain items in the library code that conceivably might have been implicated in the problems encountered by the OP.
• I have described "off-by-exact-hours" differences that were introduced by the use of certain web sites to calculate so-called "Unix timestamps". Those discrepancies were not attributable to the functions in this Library.

It would be much appreciated for the original poster to try the updated Library and let us know if the problem persists.