In log, UTC offset is mistakenly displayed as <sign><hour><seconds>

[definite]

Issue Description

This issue is also filed as Bug 2255573 - Timezone America/St_Johns is not properly represented in log timestamps

For Time Zone that has non-zero minutes. For example, America/St_Johns (-03:30).
The UTC offset become -031800 like

ns-slapd[67963]: [21/Dec/2023:20:29:56.032925110 -031800] - INFO - slapd_daemon - slapd started.  Listening on All Interfaces port 389 for LDAP requests

This is because, as pointed out by Pierre Rogier, the UTC offset is mistakenly displayed as <sign><hour><seconds>, while the expected behavior is <sign><hour><minutes>.

Package Version and Platform:

• Platform: RHDS11 (RHEL 8)
• Package and version: 389-ds-base-1.4.3.31-11.module+el8dsrv+17815+4f95348d.x86_64

Also 840161b in main.

Steps to Reproduce
Steps to reproduce the behavior:

1. Use non-zero minute time zone like America/St_Johns (UTC offset -03:30
2. Enable errorlog
3. Start the dirsrv

Expected results
In /var/log/dirsrv/slapd-EXAMPLE-COM/errors,
The UTC offset in should be displayed as [.... -0330]

Actual results
In /var/log/dirsrv/slapd-EXAMPLE-COM/errors,
The UTC offset in was displayed as [.... -031800]

[droideck]

9a9f8e6..d18807f 389-ds-base-3.0 -> 389-ds-base-3.0
bbe4f24..2bca5f9 389-ds-base-2.5 -> 389-ds-base-2.5
ec06489..951f391 389-ds-base-2.4 -> 389-ds-base-2.4
4e54618..a341ffe 389-ds-base-2.3 -> 389-ds-base-2.3
bc3d124..42c6e1a 389-ds-base-2.2 -> 389-ds-base-2.2
88fcb07..046f96e 389-ds-base-2.1 -> 389-ds-base-2.1
de82df0..bb20b35 389-ds-base-2.0 -> 389-ds-base-2.0
eaf49d9..48b0bf0 389-ds-base-1.4.3 -> 389-ds-base-1.4.3