Finally, I am able to write to and read from DS1302 chip through Raspberry PI 2 Model B, but now I noticed that time is not accurate for my timezone. In fact, it is offset by 4 hours in 24 hour format. For instance, if its 12 noon, ds1302 chip time is reading 16:00 hour. I checked the timezone and locale through raspi-config and it is exactly set for what it is suppose to be. My time zone is EST and New York/USA is what is set for. However, the weird thing about this is that Raspberry PI's system date and time is exactly as expected down to the minutes. All I do is run a command to write the system date and time to DS1302 chip. In fact, I am using wiringPI library and the sample code it came with (ds1302). That means the program I am using shouldn't be causing this. What am I doing wrong?
Why is DS1302 chip time be offset by 4 hours even though the system time is accurate for the Time Zone?
The norm for GNU/Linux systems is to set the hardware clock to UTC (I'd guess this is most likely true for POSIX systems generally) aka. "universal common time" or "coordinated universal time", neither of which abbreviates to UTC (and neither does the original French; apparently this is a bizarre compromise). Although it is not a necessity presuming the hardware clock is timezone aware, it will keep your life slightly less complicated to stick with that.
By my reading of
man hwclock, technically, the "system" time is always considered to be UTC, then adjusted at the application level according to the timezone configuration (native library functions may do this by nature and hence it is really a sort of system-application interface level). So, if your RTC is set up as the hardware clock and is set to UTC time (as per my comment on the question, it appears that it is), you should get the correct time from most applications.
You can set the hardware clock to the system time using
hwclock, and the RTC in all the desktops/laptops I've ever used seem to be timezone aware,1 so you can then use the system time "unadjusted". However, particularly if you live in an area which springs forward/falls back twice a year, there is not much advantage to this and it may bite you at some unexpected point.
1. I could be wrong about that as the kernel gets in the middle of this.
So, what you are saying is that even though ds1302 chip's time is based on UTC, Chip time will be converted to system timezone time when I read the chip.– ThNJun 20, 2016 at 17:52
Well, it depends on the software used (I've edited the middle paragraph above to correct my explanation of this), but generally it should; the "native library functions I am thinking of here are, e.g.,
gettimeofday(), and pretty much that's what everything is going to use. If you read through
man hwclocklooking for "timezone" (hit forward slash, '/', to search) you'll find some discussion of the fact that the kernel keeps its own time and this may (or may not?) be distinct from the hardware clock time but applications usually do not use or depend on it. Jun 20, 2016 at 18:06
I used to be a little OCDish about setting the hardware clock to localtime, which is why I am aware of some of the irritations this may lead to. Like I said, if it all appears to work, applications are giving the right time but querying the hardware clock gives UTC, that's the way stuff is intended to work and if you mess with it, it may mess with you ;) Fortunately you are not dual-booting the pi with MS Windows, which of course has (or had) its own contra attitude about this...I'll stop there. Jun 20, 2016 at 18:11
I've never seen a timezone-aware RTC. Do you have a reference or part number? Aug 2, 2016 at 7:45
@EdgarBonet First, thank you for what implies a more knowledgeable opinion. If that's not a rhetorical question, you didn't read the footnote. ;) When I use language like "seem" or "I think" I do it very intentionally assuming the reader is aware of the nature of the material and that, by analogy, if you ask someone for directions on the street and they say, "I think it is over there", and/or, "It seemed to be open last I went by", a normal human adult will understand they are getting a casual opinion. Anyway, my primary recommendation is at the end of the first paragraph, clarified... Aug 2, 2016 at 12:15
date), including NYC, it is correctly giving you an unadjusted UTC/GMT value.