If the base time (boot time) is pm, the next rolling time will be set to 12pm because it doesn't clear AM_PM before setting 0 to HOUR.

I actually asked James about this issue a couple of days ago.  I developed a patch similar to Takayoshi's:

index 406ff7d..28deb97 100644
--- a/src/main/java/org/jboss/logmanager/handlers/PeriodicRotatingFileHandler.java
+++ b/src/main/java/org/jboss/logmanager/handlers/PeriodicRotatingFileHandler.java
@@ -214,6 +214,7 @@ public class PeriodicRotatingFileHandler extends FileHandler {
                 calendar.clear(Calendar.DAY_OF_WEEK_IN_MONTH);
             case DAY:
                 calendar.set(Calendar.HOUR_OF_DAY, 0);
+                calendar.set(Calendar.AM_PM, 0);
             case HALF_DAY:
                 calendar.set(Calendar.HOUR, 0);
             case HOUR:

And James's response:

I started looking at this briefly, but didn't dig into it yet. I was trying to get a test case to break it, but I haven't yet. I'll have a look soon at that though. It could be as simple as that for sure. In fact, my gut is telling me that's exactly what it is.

Paul V <pvs.1.email> made a comment on jira LOGMGR-68

This will not fix the problem. The set methods of Calendar do not recalculate its time. My previous comment has a fix for this problem.

From the java doc for Calendar

Getting and Setting Calendar Field Values

The calendar field values can be set by calling the set methods. Any field values set in a Calendar will not be interpreted until it needs to calculate its time value (milliseconds from the Epoch) or values of the calendar fields. Calling the get, getTimeInMillis, getTime, add and roll involves such calculation.

Takayoshi Kimura <tkimura> made a comment on jira LOGMGR-68

Thanks Paul, you're right. HOUR should not be set other than the HALF_DAY case. Updated the pull req.

Also I'm wondering if we can change the calcNextRollover method to protected or package private for unit testing.

Kyle Lape <kyle.lape> made a comment on jira LOGMGR-68

I've talked with [~jamezp] about this case, and we worked through this issue.  He suggested a fix that included pieces from both proposed solutions.  I had also created some more tests and fixed another issue regarding the {{WEEK}} period.  I submitted a new PR: https://github.com/jboss-logging/jboss-logmanager/pull/32

Bertrand Donnet <bertrand.donnet> made a comment on jira LOGMGR-68

We also noticed this problem when migrating from JBoss EAP 6.0.1 to 6.1.0, which means LogManager from 1.3.2 to 1.4.0

Thanks for the feedback and we will wait for the fix.

James Perkins <jperkins> made a comment on jira LOGMGR-68

Pull request merged

Setting the EAP 6.1.1 flag since this has already been committed for the logmanager release for 6.1.1.

This was fixed with new version of log manager (BZ975555). PeriodicRotatingFileHandler now roll the File on 12AM even if its base time (boot time) is pm. 

Verified with EAP 6.1.1 ER7

Added a draft release note.

Setting NEEDINFO flag to request technical verification from assignee, however, at this late stage, a verification from anyone involved in the resolution of this issue will be sufficient.

If the note above is inaccurate, please reset the 'requires_doc_text' flag to '?' and leave comment with corrections.

I think that doc text is fine. I didn't work on the problem, but from my understanding you've explained it well.