ನೀವು ಎಂದಾದರೂ ಒಂದು ಪೋಸ್ಟ್ ಅನ್ನು ಲೈವ್ ಮಾಡಿದಾಗ, ನಿಮ್ಮ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಅದು ಹತ್ತು ನಿಮಿಷಗಳ ಹಿಂದೆಯೇ ಅಪ್‌ಲೋಡ್ ಆಗಿದೆ ಎಂದು ತೋರಿಸುತ್ತಿದ್ದರೂ, ಸಾರ್ವಜನಿಕ ಸೈಟ್‌ನಲ್ಲಿ ಅದು "57 years ago" ಎಂದು ತೋರಿಸುವುದನ್ನು ನೋಡಿದ್ದರೆ, ಈ ಬಗ್‌ನ ಕಿರಿಕಿರಿ ನಿಮಗೆ ತಿಳಿದೇ ಇರುತ್ತದೆ. ಇದು ಲೇಔಟ್ ಅನ್ನು ಹಾಳು ಮಾಡುವುದಿಲ್ಲ ಅಥವಾ ಯಾವುದೇ ಫೇಟಲ್ ಎರೆರ್ ಅನ್ನು ಉಂಟುಮಾಡುವುದಿಲ್ಲ. ಇದು ಕೇವಲ ನಿಮ್ಮ ಕಂಟೆಂಟ್ ಅನ್ನು ಅರ್ಧ ಶತಮಾನದಷ್ಟು ಹಳೆಯದಾಗಿಸುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ ಥೀಮ್ ಫೈಲ್‌ಗಳನ್ನು ನೋಡುತ್ತಾ ಕುಳಿತರೆ ಈ ಸಂಖ್ಯೆ ಬದಲಾಗುವುದಿಲ್ಲ.

ಈ ಸಮಸ್ಯೆ ಸಾಮಾನ್ಯ ತಪಾಸಣೆಗಳಲ್ಲೂ ಪತ್ತೆಯಾಗುವುದಿಲ್ಲ. ನೀವು single.php, archive.php, ಮತ್ತು functions.php ಫೈಲ್‌ಗಳಲ್ಲಿ ತಪ್ಪಾದ get_the_date() ಕರಲ್ ಅನ್ನು ಹುಡುಕುತ್ತೀರಿ. ಎಲ್ಲವೂ ಸರಿಯಾಗಿ ಕಾಣಿಸುತ್ತದೆ. ನೀವು ಲೈವ್ ಪೇಜ್ ಅನ್ನು ರಿಲೋಡ್ ಮಾಡಿದಾಗ, ನಿಮ್ಮ ಬೈಲೈನ್‌ನಲ್ಲಿ 1968ರ ನೆರಳು ಇನ್ನೂ ಕಾಣಿಸುತ್ತದೆ. ಆ ಹಂತದಲ್ಲಿ, ಈ ಸಮಸ್ಯೆಗೆ ನಿಮ್ಮ ಟೆಂಪ್ಲೇಟ್‌ಗಳೊಂದಿಗೆ ಸಂಬಂಧವಿರುವುದಿಲ್ಲ, ಬದಲಾಗಿ WordPress ಸ್ಟ್ಯಾಕ್ ಮೂಲಕ ಸಮಯವು ಹೇಗೆ ಪ್ರಕ್ರಿಯೆಗೊಳ್ಳುತ್ತದೆ ಎಂಬುದರೊಂದಿಗೆ ಸಂಬಂಧವಿರುತ್ತದೆ.

ಆ ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆ ಏಕೆ ಪದೇ ಪದೇ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ

"57 years ago" ಎಂಬ ಅಂಕಿಅಂಶವು ಸುಮ್ಮನೆ ಬಂದಿದ್ದಲ್ಲ. WordPress ಥೀಮ್‌ಗಳು ಹೆಚ್ಚಾಗಿ human_time_diff() ಫಂಕ್ಷನ್ ಮೂಲಕ ಸಾಪೇಕ್ಷ ಸಮಯವನ್ನು (relative time) ಪ್ರದರ್ಶಿಸುತ್ತವೆ. ಇದು ಪೋಸ್ಟ್‌ನ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ಪ್ರಸ್ತುತ ಕ್ಷಣದೊಂದಿಗೆ ಹೋಲಿಸಿ "2 hours ago" ಎಂಬಂತಹ ಸುಲಭವಾದ ವಾಕ್ಯವನ್ನು ತೋರಿಸುತ್ತದೆ. ಈ ಲೆಕ್ಕಾಚಾರವು ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡಲು, PHP ಗೆ ಸರಿಯಾದ Unix ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಬೇಕಾಗುತ್ತದೆ—ಅಂದರೆ ಜನವರಿ 1, 1970 (Unix epoch) ರಿಂದ ಕಳೆದ ಸೆಕೆಂಡುಗಳ ಎಣಿಕೆ.

ಆ ಲೆಕ್ಕಾಚಾರಕ್ಕೆ ತಲುಪುವ ಮೊದಲು ಯಾವುದೋ ಕಾರಣದಿಂದ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅಳಿಸಿಹೋದರೆ ಅಥವಾ ಹಾಳಾದರೆ, ಆ ಫಂಕ್ಷನ್ ಶೂನ್ಯವನ್ನು (ಅಥವಾ ಅಂತಹದೇ ಅಮಾನ್ಯ ಆರಂಭಿಕ ಬಿಂದುವನ್ನು) ಪ್ರಸ್ತುತ ಸಮಯದೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ ಸುಮಾರು ಐದುವರೆ ದಶಕಗಳಷ್ಟು ಹಿಂದಿನ ಸಮಯವನ್ನು ತೋರಿಸುತ್ತದೆ. ಇದು ಕಂಟೆಂಟ್‌ನಲ್ಲಿ ಸಮಯದ ಮೌಲ್ಯವು ಕಾಣೆಯಾಗಿರುವ ಅಥವಾ ತಪ್ಪಾಗಿ ಓದಲ್ಪಟ್ಟಿರುವ ಲಕ್ಷಣವೇ ಹೊರತು, ನಿಮ್ಮ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಹಳೆಯ ಬ್ಲಾಗ್ ಪೋಸ್ಟ್‌ಗಳು ತುಂಬಿರುವುದಲ್ಲ.

ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನ ವಂಚನೆ

ಈ ಬಗ್‌ನ ಅತ್ಯಂತ ಕಿರಿಕಿರಿ ಉಂಟುಮಾಡುವ ಅಂಶವೆಂದರೆ ನಿಮ್ಮ ಅಡ್ಮಿನ್ ಪ್ಯಾನಲ್‌ನ ವಿಭಿನ್ನ ವರ್ತನೆ. wp-admin ಒಳಗಡೆ, ಪೋಸ್ಟ್‌ಗಳ ಪಟ್ಟಿಯು ಸರಿಯಾದ ಪ್ರಕಟಣಾ ದಿನಾಂಕವನ್ನು ತೋರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ WordPress ಸಾಮಾನ್ಯವಾಗಿ ಅದನ್ನು ನೇರವಾಗಿ MySQL wp_posts ಟೇಬಲ್‌ನಿಂದ ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಸಾಪೇಕ್ಷ-ಸಮಯದ (relative-time) ಫಿಲ್ಟರ್ ಮೂಲಕ ಕಳುಹಿಸದೆ ಸರ್ವರ್-ಸೈಡ್‌ನಲ್ಲಿ ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡುತ್ತದೆ. ಆದರೆ, ಫ್ರಂಟ್‌ಎಂಡ್ (frontend) human_time_diff() ಅನ್ನು ಬಳಸುವ ಥೀಮ್ ಅಥವಾ ಪ್ಲಗಿನ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರಬಹುದು, ಅಥವಾ ಅದು ಡೇಟಾಬೇಸ್‌ನ ಮೂಲ ಮೌಲ್ಯವನ್ನು PHP ಟೈಮ್‌ಜೋನ್ ಪರಿವರ್ತನೆಗಳ ಮೂಲಕ ಕಳುಹಿಸಬಹುದು, ಇದನ್ನು ಬ್ಯಾಕ್‌ಎಂಡ್ ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ.

ಆದ್ದರಿಂದ ಡೇಟಾ ಸಾಮಾನ್ಯವಾಗಿ ಸರಿಯಾಗಿರುತ್ತದೆ. ಡೇಟಾಬೇಸ್ ಮತ್ತು ರೆಂಡರ್ ಮಾಡಲಾದ HTML ನಡುವಿನ ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ ತೊಂದರೆಯಾಗುತ್ತಿರುತ್ತದೆ.

PHP ವರ್ಷನ್ ಮತ್ತು ಟೈಮ್‌ಜೋನ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು

ಮೊದಲು PHP ಬಗ್ಗೆ ನೋಡೋಣ. ಹೋಸ್ಟಿಂಗ್ ಪ್ಯಾನಲ್‌ಗಳು ವರ್ಷನ್ ಬದಲಾವಣೆಯನ್ನು ಸುಲಭವೆಂದು ತೋರಿಸಬಹುದು, ಆದರೆ PHP ಪ್ರಮುಖ ಬಿಡುಗಡೆಗಳಲ್ಲಿ ಸಮಯದ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ವಿಭಿನ್ನವಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ. ಹಳೆಯ PHP 7.4 ಕೋಡ್ ಅನ್ನು ಇದ್ದಕ್ಕಿದ್ದಂತೆ PHP 8.1 ಪರಿಸರದಲ್ಲಿ ಚಲಾಯಿಸುವಾಗ, DateTime ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಖಾಲಿ ಅಥವಾ ತಪ್ಪಾದ ಸ್ಟ್ರಿಂಗ್‌ಗಳನ್ನು ಹೇಗೆ ಇನಿಶಿಯಲೈಸ್ ಮಾಡುತ್ತವೆ ಎಂಬುದರಲ್ಲಿ ಸೂಕ್ಷ್ಮ ಬದಲಾವಣೆಗಳು ಉಂಟಾಗಬಹುದು. ನಿಮ್ಮ php.ini ಫೈಲ್‌ನಲ್ಲಿ date.timezone ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸದಿದ್ದರೆ, PHP mặc định ಆಗಿ UTC ಅನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಸರ್ವರ್‌ಗೆ ಎಲ್ಲವೂ ತಿಳಿದಿದೆ ಎಂದು ಭಾವಿಸುತ್ತದೆ. ಆದರೆ WordPress ಇದಕ್ಕೆ ಒಪ್ಪದಿರಬಹುದು.

ಯಾರಾದರೂ wp-config.php ಒಳಗಡೆ ಟೈಮ್‌ಜೋನ್ ಘೋಷಣೆಯನ್ನು ಹಾರ್ಡ್‌ಕೋಡ್ (hardcoded) ಮಾಡಿದ್ದಾರೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. date_default_timezone_set( 'Asia/Kolkata' ); ನಂತಹ ಸಾಲು ಸಹಕಾರಿಯೆಂದು ಅನಿಸಬಹುದು, ಆದರೆ WordPress ತನ್ನದೇ ಆದ ಸಮಯವನ್ನು Settings > General ಅಡಿಯಲ್ಲಿ ಸೆಟ್ ಮಾಡಲಾದ ಮೌಲ್ಯದ ಮೂಲಕ ನಿರ್ವಹಿಸಲು ಬಯಸುತ್ತದೆ. PHP ಮಟ್ಟದಲ್ಲಿ ಆಫ್‌ಸೆಟ್ ಅನ್ನು ಬಲವಂತವಾಗಿ ಅನ್ವಯಿಸುವುದರಿಂದ 'race condition' ಉಂಟಾಗಬಹುದು, ಅಲ್ಲಿ ಕೋರ್ (core) ಸಮಯವು ಸ್ಥಳೀಯವಾಗಿದೆ ಎಂದು ನಂಬುತ್ತದೆ ಮತ್ತು PHP ಅದು ಸಾರ್ವತ್ರಿಕವಾಗಿದೆ ಎಂದು ನಂಬುತ್ತದೆ. ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಪರಿವರ್ತನೆಯ ಸಮಯದಲ್ಲಿ ಈ ಆಫ್‌ಸೆಟ್‌ಗಳು ಸಂಘರ್ಷಕ್ಕೊಳಗಾದಾಗ, ನಿಮ್ಮ ಟೆಂಪ್ಲೇಟ್‌ಗೆ ಮರಳುವ ಫಲಿತಾಂಶವು ಶೂನ್ಯಕ್ಕೆ ಕುಸಿಯಬಹುದು.

ಸರ್ವರ್ ಟೈಮ್‌ಜೋನ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು

ನಿಮ್ಮ MySQL ಸರ್ವರ್ ತನ್ನದೇ ಆದ ಸ್ಥಳೀಯ ಸಮಯವನ್ನು ಹೊಂದಿರುತ್ತದೆ. WordPress ಪ್ರತಿಯೊಂದು ಪೋಸ್ಟ್‌ಗಾಗಿ ಎರಡು ದಿನಾಂಕಗಳನ್ನು ಬರೆಯುತ್ತದೆ: ಸೈಟ್‌ನ ಸ್ಥಳೀಯ ಸಮಯದಲ್ಲಿ post_date, ಮತ್ತು ಯುನಿವರ್ಸಲ್ ಟೈಮ್‌ನಲ್ಲಿ post_date_gmt. ಡೇಟಾಬೇಸ್‌ನ ಗ್ಲೋಬಲ್ time_zone ಬದಲಾದರೆ—ಉದಾಹರಣೆಗೆ ಮೈಗ್ರೇಷನ್ ನಂತರ SYSTEM ನಿಂದ +00:00 ಕ್ಕೆ ಬದಲಾದರೆ—PHP ನ strtotime() ಶೇಖರಿಸಿದ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ನಿರೀಕ್ಷಿತ ಮೌಲ್ಯದೊಂದಿಗೆ ಹೊಂದಿಸಲು ವಿಫಲವಾಗಬಹುದು. ಡೇಟಾಬೇಸ್ ಇನ್ನೂ 2024-03-15 14:30:00 ಅನ್ನು ಸಂಗ್ರಹಿಸಿರಬಹುದು, ಆದರೆ ಅದರ ಸುತ್ತಲಿನ ಸಂದರ್ಭ ಬದಲಾಗುತ್ತದೆ ಮತ್ತು PHP ನಲ್ಲಿ ಪಾರ್ಸ್ ಮಾಡಿದ ಔಟ್‌ಪುಟ್ 'false' ಅಥವಾ 'null' ಆಗುತ್ತದೆ.

ನೈಜ ಉದಾಹರಣೆ: ಮ್ಯಾನೇಜ್ಡ್ ಹೋಸ್ಟ್ ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಅನ್ನು SYSTEM ಸಮಯ ಹೊಂದಿರುವ MySQL 5.7 ರನ್ ಮಾಡುವ ನೋಡ್‌ನಿಂದ, ಕಟ್ಟುನಿಟ್ಟಾದ UTC ಗೆ ಸೆಟ್ ಮಾಡಲಾದ MariaDB 10.11 ರನ್ ಮಾಡುವ ಕ್ಲಸ್ಟರ್‌ಗೆ ವರ್ಗಾಯಿಸುತ್ತದೆ. ನಿಮ್ಮ ಥೀಮ್ ಬದಲಾಗುವುದಿಲ್ಲ. ನಿಮ್ಮ WordPress ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಬದಲಾಗುವುದಿಲ್ಲ. ಆದರೂ get_the_time( 'U' )—ಅಂದರೆ Unix ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಫಾರ್ಮ್ಯಾಟ್—ಕೆಲವು ಪೋಸ್ಟ್‌ಗಳಿಗೆ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಖಾಲಿ ಮೌಲ್ಯವನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಸಾಪೇಕ್ಷ-ಸಮಯದ ಫಂಕ್ಷನ್ ಆ ಎಪೋಕ್-ಸೀರೋ (epoch-zero) ಲೆಕ್ಕಾಚಾರಕ್ಕೆ ಮರಳುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ಟೈಮ್‌ಜೋನ್, ಡೇಟಾಬೇಸ್ ಟೈಮ್‌ಜೋನ್ ಮತ್ತು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಗಡಿಯಾರವನ್ನು ಒಂದೇ ರೀತಿಯಲ್ಲಿ ಹೊಂದಿಸುವುದೇ ಇದಕ್ಕೆ ಪರಿಹಾರವಾಗಿದೆ, ಇದರಿಂದ WordPress ಯಾವ ರೆಫರೆನ್ಸ್ ಫ್ರೇಮ್ ಅನ್ನು ಬಳಸಬೇಕೆಂದು ಊಹಿಸುವ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.

ಡೇಟಾಬೇಸ್ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಫಾರ್ಮ್ಯಾಟ್‌ಗಳು

WordPress core stores post dates in MySQL DATETIME columns, not TIMESTAMP fields. That distinction matters because DATETIME holds a calendar value without_zone awareness in older MySQL versions, whereas TIMESTAMP converts everything to UTC behind the scenes. If a plugin or migration tool has altered your wp_posts schema, or if an old backup restored invalid zero dates into the table, WordPress may read a value like 0000-00-00 00:00:00 and quietly hand it off to your theme.

Modern MySQL modes, particularly NO_ZERO_DATE and STRICT_TRANS_TABLES, reject those zero placeholders. If a backup script inserted them during a migration, the database might have truncated or nulled them on import. You can verify this quickly with a direct SQL query:

SELECT ID, post_title, post_date, post_date_gmt 
FROM wp_posts 
WHERE post_status = 'publish' 
ORDER BY post_date DESC 
LIMIT 10;

If the raw columns look correct but the site still displays ancient history, the corruption is happening after the query. If the columns themselves contain zeroes, you have found the leak in the plumbing.

Plugin Conflicts with Date Functions

Plugins that filter date output are common culprits. Multilingual tools such as WPML or Polylang hook into get_the_date to translate month names. Caching plugins intercept the final HTML. Either layer can accidentally pass an unformatted string into a function expecting a Unix integer.

A translation plugin might replace “March 15, 2024” with its localized equivalent, but if a theme then pipes that localized string into strtotime() inside a custom function, the parser fails on non-English characters and returns false. That false value hits human_time_diff(), which compares zero against now, producing the infamous half-century gap.

Object cache layers complicate this further. Redis or Memcached can store a serialized WP_Post object from a request that briefly failed to parse the date. Every subsequent visitor receives that corrupted object straight from RAM, bypassing the database entirely. The issue persists on the live site because your production stack has cache infrastructure that your local install lacks.

A Practical Debugging Checklist

Because the symptom hides deep in the stack, you need to peel layers systematically until the dates snap back into place.

  1. Query the database directly. Open phpMyAdmin or run WP-CLI and inspect the raw post_date values. If they are correct, the database is not the problem.
  2. Switch to a default theme. Activate Twenty Twenty-Four or Twenty Twenty-Three. If the bug disappears, audit your active theme and child theme for custom functions wrapping time output.
  3. Silence the plugins. Rename the /wp-content/plugins folder temporarily, or disable all plugins from the dashboard. Re-enable them one by one, checking the frontend after each activation.
  4. Read the error log. Look for timezone warnings, DateTime errors, or strtotime() complaints. They often point to the exact