get_calendar() shows incorrect month-end due to current_time() timezone issue

[smilkobutawp]

The get_calendar() function in WordPress incorrectly calculates the number of days in the current month when the site timezone is set to UTC+9 (e.g., Asia/Tokyo) and the current time is near the end of the month (e.g., July 31st around 22:00–23:59 JST).
🔁 Steps to Reproduce:

1. Set your WordPress site timezone to Asia/Tokyo (UTC+9).

2. Visit a page that displays the default calendar widget.

3. On July 31, 2025, at 22:37 JST, observe that the calendar for July only shows up to the 30th, even though July has 31 days.

4. Inspect wp-includes/general-template.php, where get_calendar() uses the following:

$thisyear = (int) current_time( 'Y' );
$thismonth = (int) current_time( 'm' );
$unixmonth = mktime( 0, 0, 0, $thismonth, 1, $thisyear );
$last_day = gmdate( 't', $unixmonth );

This calculation yields an incorrect $thismonth = 8 (August), causing $last_day = 30 instead of 31 for July.
🧠 Technical Cause:

current_time('Y') and current_time('m') are localized string values, but they are influenced by UTC time logic internally, especially near the date change boundary. As a result, the calendar may "roll over" to the next month prematurely.
✅ Suggested Fix:

Use current_time('timestamp') or better yet, rely on the correct timezone-aware approach using wp_timezone():

$dt = new DateTimeImmutable( 'now', wp_timezone() );
$thisyear = (int) $dt->format( 'Y' );
$thismonth = (int) $dt->format( 'm' );
$unixmonth = $dt->setDate( $thisyear, $thismonth, 1 )->getTimestamp();
$last_day = gmdate( 't', $unixmonth );

✅ Confirmed Result:

On 2025-07-31 22:37 JST, this code correctly yields:

$thisyear = 2025
$thismonth = 7
$last_day = 31

This provides accurate calendar generation behavior, aligned with local timezone settings.

Please consider updating get_calendar() to use timezone-aware logic in future versions to prevent subtle bugs in calendar rendering for international users.

Trac ticket: [](https://core.trac.wordpress.org/ticket/63772)

fixed bug for Calculation Day of the month

Trac ticket: https://core.trac.wordpress.org/ticket/63772

i am closing this PR

I am closing this PR

fix calendar bug calculated correct date of the month
Trac ticket: https://core.trac.wordpress.org/ticket/63772

addded current date as dynamic value and passed in function mktime
Trac ticket: https://core.trac.wordpress.org/ticket/63772

added current day as dynamic value and passed into mktime function

Trac ticket: https://core.trac.wordpress.org/ticket/63772

[autotutorial]

Replying to smilkobutawp:

The get_calendar() function in WordPress incorrectly calculates the number of days in the current month when the site timezone is set to UTC+9 (e.g., Asia/Tokyo) and the current time is near the end of the month (e.g., July 31st around 22:00–23:59 JST).
🔁 Steps to Reproduce:

1. Set your WordPress site timezone to Asia/Tokyo (UTC+9).

2. Visit a page that displays the default calendar widget.

3. On July 31, 2025, at 22:37 JST, observe that the calendar for July only shows up to the 30th, even though July has 31 days.

4. Inspect wp-includes/general-template.php, where get_calendar() uses the following:

$thisyear = (int) current_time( 'Y' );
$thismonth = (int) current_time( 'm' );
$unixmonth = mktime( 0, 0, 0, $thismonth, 1, $thisyear );
$last_day = gmdate( 't', $unixmonth );

This calculation yields an incorrect $thismonth = 8 (August), causing $last_day = 30 instead of 31 for July.
🧠 Technical Cause:

current_time('Y') and current_time('m') are localized string values, but they are influenced by UTC time logic internally, especially near the date change boundary. As a result, the calendar may "roll over" to the next month prematurely.
✅ Suggested Fix:

Use current_time('timestamp') or better yet, rely on the correct timezone-aware approach using wp_timezone():

$dt = new DateTimeImmutable( 'now', wp_timezone() );
$thisyear = (int) $dt->format( 'Y' );
$thismonth = (int) $dt->format( 'm' );
$unixmonth = $dt->setDate( $thisyear, $thismonth, 1 )->getTimestamp();
$last_day = gmdate( 't', $unixmonth );

✅ Confirmed Result:

On 2025-07-31 22:37 JST, this code correctly yields:

$thisyear = 2025
$thismonth = 7
$last_day = 31

This provides accurate calendar generation behavior, aligned with local timezone settings.

Please consider updating get_calendar() to use timezone-aware logic in future versions to prevent subtle bugs in calendar rendering for international users.

WordPress sets UTC timezone as default and the mktime function also used UTC. ​https://github.com/WordPress/WordPress/blob/master/wp-settings.php#L72 If the theme, plugin or anything else is different from UTC it is not a CORE WordPress bug.

<?php

$original = date_default_timezone_set( 'Europe/Berlin');
$WordPress = date_default_timezone_set('UTC');
$tz = timezone_open( 'Asia/Tokyo' );
$date = date_create( '2025-07-30 22:30:00', $tz );
$thisyear = (int) date_format( $date,  'Y' );
$thismonth = (int) date_format( $date, 'm' );
$unixmonth = mktime( 0, 0, 0, $thismonth, 1, $thisyear ); // if set Europe/Berlin 1751320800 (+02:00)
$last_day = gmdate( 't', $unixmonth );
var_dump($unixmonth, $thismonth, $last_day, $WordPress);
?>