Bug fixes:

1) Handling of 12/24 hour bit :

Hour indication was wrong when AM/PM bit was set to 12 hour (for instance when the RTC module came from factory. The following code was inserted to convert the AM/PM time to 24 hour.

// Compute minutes
minutes = rtc.datetime.minutes.tens * 10 + rtc.datetime.minutes.units;
		
// Compute hours, taking 12/24 hour into account
hours   = ( rtc.datetime.hours.tens & 1) * 10 + rtc.datetime.hours.units; // base time
if  (rtc.datetime.hours.op12_24) {  // 12 hour mode?
	if (rtc.datetime.hours.tens >>1 ) { // PM
		if ( hours !=12) hours = hours + 12;  // 1:00 PM to 11:59 PM ->  13:00 to 23:59
	} else {
		if ( hours ==12) hours = hours - 12;  // 12:00 AM to 12:59 AM ->  00:00 to 00:59
	}
} else { // 24 hour mode
	hours   = rtc.datetime.hours.tens   * 10 + rtc.datetime.hours.units;
}

A second provision was to set the 12/24 hour bit whenever the hour or the minute is advanced right before write the changed time to RTC

...  
rtc.datetime.hours.op12_24 = 0; // force 24 hour mode
writeRtc();
}

2) Hour changing every power up:

This was harder to track and to make a long story short, I have used a workaround and called it a day.

The RA3/MCLR line behaves like it was receiving ghost presses after power up, causing the clock to advance 1 or 2 hours every time  Such pulses did not appear if the button connected to this line was held down during power up.
I have initially suspected from the de-bounce capacitor on the pin, and even tried to delay the startup during up one second without any change on the behavior. Nevertheless this problem does not occur on the RA1 button.

At the end I have found that inverting the logic of the pin, making "un-pressed" as true and "pressed" as false caused the "ghost pulses" do disappear with the only side effect being the time advancing when the button is pressed (instead of when it was pressed then released).

// Button Stuff 
#define BUTTON1 RA3  // !RA3
#define BUTTON2 RA1  // !RA1