जर तुम्ही कधी एखादी पोस्ट लाईव्ह केली असेल आणि सार्वजनिक साइटवर ती "५७ वर्षांपूर्वी" अशी दिसत असेल, तर दुसरीकडे तुमचे डॅशबोर्ड शांतपणे सांगत असेल की ती दहा मिनिटांपूर्वीच अपलोड झाली आहे, तर तुम्हाला या बगचा (bug) नेमका त्रास काय असतो हे समजेल. यामुळे लेआउट बिघडत नाही. यामुळे कोणताही 'फेटल एरर' (fatal error) येत नाही. हे फक्त तुमच्या कंटेंटला अर्ध्या शतकाने जुने करते, आणि तुमच्या थीम फाइल्सकडे तासनतास पाहत राहिल्यानेही हा आकडा बदलणार नाही.

ही समस्या सामान्य तपासणीतही सुटत नाही. तुम्ही single.php, archive.php, आणि functions.php मध्ये get_the_date() च्या चुकीच्या वापराचा शोध घेता. सर्व काही सामान्य दिसते. तुम्ही लाईव्ह पेज रिलोड करता. तरीही १९६८ चा तो 'भूतकाळ' तुमच्या बायलाईनमध्ये (byline) कायम राहतो. अशा वेळी, ही समस्या तुमच्या टेम्पलेट्सशी संबंधित नसून ती वर्डप्रेस स्टॅक (WordPress stack) मध्ये वेळ (time) कशा प्रकारे हाताळली जाते, यावर अवलंबून असते.

तो विशिष्ट आकडा वारंवार का दिसतो?

"५७ वर्षांपूर्वी" हा आकडा कोणताही योगायोग नाही. वर्डप्रेस थीम्स अनेकदा human_time_diff() फंक्शनद्वारे 'रिलेटिव्ह टाइम' (relative time) प्रदर्शित करतात, जे पोस्टच्या टाइमस्टॅम्पची (timestamp) तुलना सध्याच्या वेळेशी करते आणि "२ तासांपूर्वी" सारखे सोपे वाक्य छापते. हे गणित अचूक होण्यासाठी, PHP ला एका वैध Unix timestamp ची गरज असते—म्हणजेच १ जानेवारी १९७० (Unix epoch) पासूनचे सेकंदांचे मोजमाप.

जेव्हा ही गणना होण्यापूर्वीच काहीतरी टाइमस्टॅम्प काढून टाकते किंवा खराब करते, तेव्हा हे फंक्शन वारंवार 'शून्य' (किंवा तत्सम अवैध सुरुवातीचा बिंदू) आणि सध्याची वेळ यांची तुलना करते. परिणामी, सुमारे साडेपाच दशकांचा कालावधी दिसतो, जो दरवर्षी एक वर्ष पुढे सरकतो. हे चुकीच्या किंवा गहाळ झालेल्या वेळेच्या मूल्याचे लक्षण आहे, तुमच्या डेटाबेसमध्ये जुन्या ब्लॉग पोस्ट्स असल्यामुळे नाही.

डॅशबोर्डचा भ्रम

या बगचा सर्वात त्रासदायक भाग म्हणजे तुमच्या ॲडमिन पॅनेलचे दोन वेगळे स्वभाव. wp-admin मध्ये, 'Posts' लिस्टमध्ये प्रकाशनाची योग्य तारीख दिसते कारण वर्डप्रेस अनेकदा ती थेट MySQL च्या wp_posts टेबलमधून घेते आणि 'रिलेटिव्ह-टाइम फिल्टर' न वापरता सर्व्हर-साइडवर फॉरमॅट करते. मात्र, फ्रंटएंड (frontend) एखाद्या थीम किंवा प्लगइनवर अवलंबून असू शकते जे human_time_diff() कॉल करते, किंवा ते डेटाबेसचे मूळ मूल्य PHP टाइमझोन कन्व्हर्जनच्या (timezone conversions) प्रक्रियेतून पाठवू शकते, ज्याला बॅकएंड पूर्णपणे वगळते.

त्यामुळे डेटा सहसा सुरक्षित असतो. डेटाबेस आणि रेंडर केलेले HTML यांच्यामधील 'पाईपलाईन' मध्ये अडथळा निर्माण होतो.

PHP व्हर्जन आणि टाइमझोन सेटिंग्ज

PHP पासून सुरुवात करूया. होस्टिंग पॅनेल व्हर्जन बदलणे सोपे वाटू शकते, परंतु PHP वेगवेगळ्या मुख्य व्हर्जनमध्ये 'टाइम ऑब्जेक्ट्स' (time objects) वेगवेगळ्या पद्धतीने हाताळते. अचानक PHP 8.1 वातावरणात जुना PHP 7.4 कोड चालवणाऱ्या साइटमध्ये DateTime ऑब्जेक्ट्स रिकाम्या किंवा चुकीच्या स्ट्रिंग्स कशा इनिशियलाइज (initialize) करतात, यामध्ये सूक्ष्म बदल आढळू शकतात. जर तुमच्या php.ini फाईलमध्ये date.timezone डिफाइन केलेले नसेल, तर PHP डीफॉल्टनुसार UTC वापरते आणि सर्व्हरला सर्व माहिती आहे असे मानून चालते. वर्डप्रेस याला विरोध करू शकते.

कोणी wp-config.php मध्ये टाइमझोन डिक्लेरेशन हार्डकोड केले आहे का ते तपासा. date_default_timezone_set( 'Asia/Kolkata' ); सारखी ओळ उपयुक्त वाटू शकते, परंतु वर्डप्रेस Settings > General अंतर्गत सेट केलेल्या मूल्याद्वारे स्वतःची वेळ व्यवस्थापित करण्याची अपेक्षा करते. PHP-पातळीवर ऑफसेट (offset) लादल्यामुळे 'रेस कंडिशन' (race condition) निर्माण होऊ शकते, जिथे वर्डप्रेस कोअरला वेळ स्थानिक वाटते आणि PHP ला ती युनिव्हर्सल वाटते. जेव्हा टाइमस्टॅम्प कन्व्हर्जन दरम्यान हे ऑफसेट्स एकमेकांशी भिडतात, तेव्हा तुमच्या टेम्पलेटला मिळणारे रिझल्ट शून्य होऊ शकतात.

सर्व्हर टाइमझोन कॉन्फिगरेशन्स

तुमच्या MySQL सर्व्हरची स्थानिक वेळेबद्दल स्वतःची संकल्पना असते. वर्डप्रेस प्रत्येक पोस्टसाठी दोन तारखा लिहिते: साइटच्या स्थानिक वेळेनुसार 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 चालवणाऱ्या क्लस्टरवर हलवतो. तुमची थीम बदलत नाही. तुमची वर्डप्रेस सेटिंग्ज बदलत नाहीत. तरीही get_the_time( 'U' )—म्हणजेच Unix timestamp फॉरमॅट—काही पोस्टसाठी अचानक रिकामी व्हॅल्यू देतो आणि रिलेटिव्ह-टाइम फंक्शन पुन्हा त्या 'epoch-zero' गणनेकडे वळते. याचे निराकरण म्हणजे ॲप्लिकेशन टाइमझोन, डेटाबेस टाइमझोन आणि ऑपरेटिंग सिस्टम क्लॉक यांचा ताळमेळ बसवणे, जेणेकरून वर्डप्रेसला कोणता संदर्भ वापरावा याचा अंदाज लावावा लागणार नाही.

डेटाबेस टाइमस्टॅम्प फॉरमॅट्स

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