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?

  • 1
    "its 12 noon, ds1302 chip time is reading 16:00 hour" -> That's not 6 hours, that's 4 hours (16 - 12 = 4; using a 24 hour clock 16:00 == 4 pm, 21:00 == 9 pm, etc). Which means, since much of the EST region is now on daylight savings time (aka. EDT time, D for daylight, S for standard -- have a closer look at the output from date), including NYC, it is correctly giving you an unadjusted UTC/GMT value.
    – goldilocks
    Commented Jun 20, 2016 at 16:57
  • Ouch!!! Made a mistake there... you are right...
    – ThN
    Commented Jun 20, 2016 at 17:37
  • "That means the program I am using shouldn't be causing this. What am I doing wrong?" -> As per my answer, there's nothing wrong. That's what most people will want, because otherwise the system is more likely to end up screwed up (notice, yours is not). You did not include the code, but even if it includes specifying a timezone, it most likely will take this into account and set the RTC to UTC because that is the normal, most functional practice. If it doesn't involve specifying the timezone, it is simple for the library to get it from the system and take that into account.
    – goldilocks
    Commented Jun 20, 2016 at 17:52

1 Answer 1


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.
    – ThN
    Commented Jun 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 hwclock looking 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.
    – goldilocks
    Commented 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.
    – goldilocks
    Commented Jun 20, 2016 at 18:11
  • I've never seen a timezone-aware RTC. Do you have a reference or part number? Commented 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...
    – goldilocks
    Commented Aug 2, 2016 at 12:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.