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?
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.