# Bug Report: Missing day "25" in Date type Custom Fields dropdowns

## 1. General Information

* **Title:** Anomalous skip from day 24 to 26 in Date selectors (Custom Fields).
* **Affected Module:** User Interface (UI) / Custom Field Rendering API.
* **Severity:** Major (Prevents accurate data entry for business/legal dates).
* **Priority:** High.

## 2. Issue Summary

In all platform forms (ticket creation, editing, or filters), the dropdown lists generated for "Date" type Custom Fields fail to display the 25th day of the month. The list visually counts `... 22, 23, 24, 26, 27 ...`, completely blocking users from recording that exact day regardless of the month or year selected.

## 3. Environment & Technical Context

* **Application:** MantisBT.
* **Affected Field Type:** Custom Fields (Type: Date).
* **Infrastructure:** Shared Hosting (Bluehost).
* **Control Panel:** cPanel (MultiPHP Manager, MultiPHP INI Editor).
* **PHP Version:** 8.0.x (Also tested on 8.1 and 8.2).
* **Local Timezone:** `America/Guayaquil` (GMT-5, no local Daylight Saving Time).

## 4. Steps to Reproduce

1. Log in to MantisBT.
2. Navigate to "Report Issue" or edit an existing ticket.
3. Locate any custom field configured as a "Date".
4. Click the dropdown menu corresponding to the "Day" selector.
5. Scroll down the numeric list.
   **Result:** Upon reaching number 24, the subsequent value is 26. Day 25 is missing.

## 5. Expected vs. Actual Behavior

* **Expected Behavior:** The day selector should be a static, uninterrupted list containing values from `1` to `31`.
* **Actual Behavior:** The selector evaluates time dynamically, skipping a number and rendering `24` followed immediately by `26`.

## 6. System Impact

1. **Loss of Precision:** Users cannot input legal, procedural, or exact dates falling on the 25th, forcing them to enter false data (24 or 26).
2. **Data Integrity (Destructive Workaround):** Attempts to force a fix by altering the system's base timezone to `UTC` (which has no DST) corrupt the database. This workaround saves all notes, tracking, and ticket creation dates with a 5-hour offset based on our local time.

## 7. Troubleshooting & Tests Performed

Multiple interventions were performed at the server (cPanel) and application levels to rule out local configuration errors. **All failed**, confirming that the issue resides within the hardcoded rendering logic of MantisBT's Core.

### Test 1: Modifying `php.ini` via cPanel
* **Action:** Added the directive `date.timezone = "America/Guayaquil"` for the affected domain via cPanel's MultiPHP INI Editor.
* **Result:** FAILED. The server assimilated the change, but the Mantis selector continued to omit day 25.

### Test 2: Modifying `config_inc.php` (Global Variables)
* **Action:** Verified and strictly set Mantis's environment variable `$g_default_timezone = 'America/Guayaquil';` in the main configuration file.
* **Result:** FAILED. The platform loads the correct timezone for the front-end, but the date selector rendering function ignores it.

### Test 3: Direct PHP Timezone Injection
* **Action:** Injected the native function `date_default_timezone_set('America/Guayaquil');` at line 2 of `config_inc.php` to force the PHP engine to process the code without DST from the very first millisecond of execution.
* **Result:** FAILED. This demonstrates that the rendering function uses absolute time parameters (Epoch) and conflicts with the underlying shared server OS hardware.

### Test 4: PHP Version Change (OPcache Flush)
* **Action:** Migrated the domain from PHP 8.0 to PHP 8.1/8.2 using MultiPHP Manager to force a process pool restart and clear potential server cache locks.
* **Result:** FAILED. The issue persists across different PHP versions.

### Test 5: UTC Workaround (Discarded)
* **Action:** Tested setting `date_default_timezone_set('UTC');` and `$g_default_timezone = 'UTC';`.
* **Result:** DISCARDED DUE TO COLLATERAL DAMAGE. Although this visually fixes the selector (because UTC has no DST transitions), it destroys system integrity by offsetting the creation/editing timestamps of absolutely all platform records.

## 8. Root Cause Analysis

The issue is not an environment configuration error, but a **design flaw in MantisBT's rendering logic** (typically located in files like `core/custom_field_api.php` or `core/print_api.php`, depending on the version).

**Failure Mechanism:**
1. Instead of printing the day selector using a simple numeric array (1 to 31), the legacy code builds the selector options by iterating over a timestamp object or using functions like `mktime()`.
2. To advance from one day to the next within the loop, the system adds a fixed 24-hour block (`86400` seconds) to an old base reference date.
3. The PHP engine inherits historical Daylight Saving Time (DST) rules from the shared server's underlying operating system. When the iteration hits a historical date where the clock was moved forward (resulting in a 23-hour day), adding a full 24 hours to day "24" causes a mathematical overflow.
4. The calculation completely skips the specific hour required for day 25 to exist, rendering day 26 in the next HTML iteration.

## 9. Proposed Resolution

The function that generates the HTML `<select>` output for days in Custom Fields must be modified or overridden.

**Required Fix:**
Replace the iteration based on mathematical manipulation of `timestamps` or `mktime()` with a blind structural iterator. Relying on fixed-second math for UI calendar generation is highly vulnerable to DST anomalies.

```php
// Suggested correction for rendering the days list
for ( $i = 1; $i <= 31; $i++ ) {
    $t_selected = ( $i == $p_day ) ? ' selected="selected"' : '';
    echo '<option value="' . $i . '"' . $t_selected . '>' . str_pad( $i, 2, '0', STR_PAD_LEFT ) . '</option>';
}
```

This completely decouples the visual element of the selector from any timezone logic or server-side time calculations, permanently preventing Daylight Saving Time conflicts.