Why This Chapter Matters

Dates are often treated as small labels placed near the title of an article.

For a programmer, however, dates are not decorative information. They are part of the meaning, reliability and history of the content.

Consider these statements:

The government provides a subsidy of 40 per cent.

The average production cost is ₹32 per kilogram.

This technology is suitable for small processing units.

The company operates in twelve states.

Each statement may have been correct when it was written. But is it still correct today?

Without a publication date, an update date or some indication of the period being discussed, the reader cannot judge whether the information remains relevant.

The same problem applies to search engines and AI systems. 

When an AI system finds two pages containing different figures, regulations or recommendations, it needs signals that help it understand which information is newer, which is historical and which has actually been revised.

A visible date alone is not enough.

A webpage may display “Last Updated: Today” even though only a spelling mistake was corrected. Another page may contain substantially revised information while still showing its original publication date. 

A report may be replaced with a new version without preserving the earlier document. A testimonial may appear recent even though it was given ten years ago.

These practices create confusion rather than freshness.

A programmer must therefore build a content system that can distinguish between:

• when the content was first published,

• when its information was meaningfully revised,

• when a file was uploaded,

• when a technical correction was made,

• when the information was reviewed,

• and when it should be reviewed again.

These are not always the same dates.

The programmer is not expected to decide whether an agricultural recommendation, government rule or market figure is still correct. That judgement belongs to the organisation or subject expert.

The programmer’s responsibility is to create the fields, controls, reminders, revision records and machine-readable signals that allow freshness to be managed honestly.

This chapter explains how dates and content freshness should be built into the website as a system—not added later as cosmetic labels.

________________________________________ 

Rule 5.1; Preserve the Original Publication Date

The Rule

Every substantial content item should permanently retain the date on which it was first made publicly available.

Why This Rule Exists

The publication date establishes the beginning of the content’s public history.

It tells the reader when the article, report, case study, video, dataset or announcement first appeared.

This date should not disappear merely because the content is later edited.

For example, suppose an article titled:

Cost of Establishing a One-Acre Polyhouse

was first published on 12 March 2025.

In July 2026, the organisation updates equipment prices and government subsidy details.

The article is still the article originally published on 12 March 2025. Its history should not be rewritten to make it appear as though it was newly created in July 2026.

The correct display would be:

Published: 12 March 2025

Last Updated: 18 July 2026

The first date establishes origin. The second establishes revision.

Both are useful.

What Most Programmers Do

Many content management systems contain only one date field.

Whenever the page is edited, the old date is replaced by the new date.

As a result:

• an old article appears newly published,

• the original history is lost,

• archive pages become misleading,

• and users cannot distinguish new content from revised content.

In other systems, the displayed date is taken from the file upload date, server timestamp or database modification time. These may have little relationship to the actual publication of the information.

Better Practice

Create a separate, permanent field for:

Original Publication Date

Once the content is publicly published, this field should not change during normal editing.

Changing it should require a deliberate administrative action and, where appropriate, permission from an authorised editor.

The programmer should also distinguish between:

• content creation date,

• first publication date,

• and database record creation time.

A draft may have been created on 5 March, approved on 10 March and published on 12 March. The visitor normally needs to see the publication date—not the date on which the database record was created.

Example

A case study is prepared internally on 2 February 2026 and uploaded as a draft on 8 February 2026. It is approved and made public on 20 February 2026.

The public page should show:

Published: 20 February 2026

The internal administrative record may preserve:

Draft Created: 2 February 2026

Uploaded to CMS: 8 February 2026

Published: 20 February 2026

These dates serve different purposes and should not be confused.

Programming Impact

This requires:

• a dedicated publication-date field,

• protection against accidental overwriting,

• separate draft and publication timestamps,

• correct sorting of archive pages,

• clear CMS labels,

• and accurate structured data.

 ________________________________________

Rule 5.2; Show “Last Updated” Separately and Honestly

The Rule

Display a “Last Updated” date only when the information, conclusion, figures, instructions or other meaningful content has actually changed.

Why This Rule Exists

An update date tells the reader that the content has been reconsidered or revised after its original publication.

It should therefore communicate real editorial activity.

Changing a comma, correcting a spelling mistake, adjusting line spacing or replacing a photograph does not necessarily make the information fresher.

If every minor technical edit changes the visible update date, a page can appear current without having undergone any meaningful review.

This creates false freshness.

Meaningful changes may include:

• replacing outdated figures,

• incorporating new regulations,

• revising technical instructions,

• adding significant findings,

• correcting a factual error,

• changing a recommendation,

• updating product availability,

• revising prices or cost estimates,

• or adding substantial new sections.

Minor changes may include:

• correcting spelling,

• changing punctuation,

• adjusting formatting,

• repairing a broken link,

• compressing an image,

• correcting a typographical error that does not change meaning,

• or making a technical accessibility improvement.

Minor changes may be recorded internally, but they do not always justify changing the visible “Last Updated” date.

What Most Programmers Do

The database automatically changes the modification timestamp whenever anyone presses “Save.”

The visible page then displays this technical timestamp as “Last Updated.”

Consequently, all of the following may falsely make a page appear newly revised:

• adding a space,

• correcting a heading style,

• changing an image filename,

• updating metadata,

• repairing HTML,

• or opening and saving the record without changing the content.

Better Practice

Separate the database’s automatic modification time from the editorial “Last Updated” date.

The CMS may record every technical save internally, but the visible update date should change only through a deliberate editorial decision.

A useful workflow could ask the editor:

Does this revision meaningfully change the information presented to the reader?

Options:

• Yes—update the public “Last Updated” date.

• No—record the technical edit internally only.

Example 1: Minor correction

Original sentence:

The scheme was launched in 2025.

Corrected sentence:

The scheme was launched in 2024.

This is a factual correction and may justify an update date because the meaning has changed.

Example 2: Typographical correction

Original sentence:

The scheme was launced in 2024.

Corrected sentence:

The scheme was launched in 2024.

The information has not changed. The public update date need not change.

Example 3: Revised figures

Original page:

Estimated machinery cost: ₹18 lakh.

Revised page:

Estimated machinery cost: ₹24 lakh, based on July 2026 supplier quotations.

This is a meaningful update.

The page should show:

Published: 12 March 2025

Last Updated: 18 July 2026

Updated for: Revised machinery prices based on July 2026 quotations.

Programming Impact

This affects:

• CMS workflow,

• editorial permissions,

• database fields,

• automatic timestamps,

• public page templates,

• update logs,

• and audit history.

 ________________________________________

Rule 5.3; Explain What Was Updated

The Rule

When a substantial page is revised, briefly state what changed and why.

Why This Rule Exists

A date alone tells the reader that something changed. It does not tell them what changed.

Consider:

Last Updated: 18 July 2026

The reader still does not know whether:

• one link was repaired,

• the entire report was rewritten,

• cost figures were revised,

• a government rule changed,

• or a factual error was corrected.

A short update note makes the revision meaningful.

It also helps AI systems and future editors understand the difference between versions.

What Most Programmers Do

Only the update date is displayed.

No field exists to explain the revision.

Sometimes an editor adds an informal note inside the article, but there is no consistent format across the website.

Better Practice

Provide a structured field called something such as:

Reason for Update

or:

What Changed

This may be displayed directly below the dates.

Example

Published: 12 March 2025

Last Updated: 18 July 2026

Updated for: New government guidelines and revised cost figures.

More detailed example

Published: 8 January 2024

Last Updated: 25 June 2026

What Changed: The eligibility criteria, application deadline and subsidy ceiling were revised following the June 2026 government notification.

The explanation need not be long. One clear sentence is often enough.

For major documents, a more detailed change summary may be provided:

Changes in Version 3.0

• Revised machinery capacity from 500 kilograms to 750 kilograms per day.

• Updated electricity consumption estimates.

• Added food-safety compliance requirements.

• Removed the discontinued subsidy reference.

Programming Impact

This requires:

• an update-reason field,

• version notes,

• suitable display templates,

• structured revision records,

• and clear editorial controls.

 ________________________________________

Rule 5.4; Maintain Revision History for Important Documents

The Rule

For reports, manuals, policies, technical documents, datasets and other important resources, preserve a clear history of major versions.

Why This Rule Exists

Some content is gradually improved over several years.

A food-costing framework may begin as Version 1.0, receive revised assumptions in Version 2.0 and include new taxation rules in Version 3.0.

Simply replacing the old document with the new one creates several problems.

People who downloaded the earlier version cannot determine whether their copy is still current. Other websites may continue linking to an old file. Internal teams may unknowingly use different versions. Historical reasoning may be lost.

A revision history prevents this confusion.

What Most Programmers Do

A new document is uploaded using filenames such as:

report-final.pdf

report-final-new.pdf

report-final-latest.pdf

report-final-corrected-2.pdf

The old file may be deleted or overwritten.

There is no reliable way to know:

• which version is current,

• when each version was issued,

• what changed,

• or whether an earlier version should still be available.

Better Practice

Assign formal version numbers to major documents.

For example:

Version 1.0 — Initial publication

Version 1.1 — Minor corrections

Version 2.0 — Substantial revision

Version 3.0 — New methodology introduced

The current page may show:

Current Version: 3.0

Released: 18 July 2026

Supersedes: Version 2.1 dated 10 November 2025

A revision table may look like this:

Older versions may remain available where they have historical, legal or research value. Where they should not be used, clearly mark them:

Archived Version—Do Not Use for Current Decisions

Programming Impact

This influences

• document versioning,

• file storage,

• stable URLs,

• archive management,

• download pages,

• change logs,

• permissions,

• and auditability.

 ________________________________________

Rule 5.5; Attach Dates to Every Time-Sensitive Knowledge Asset

The Rule

Do not limit dates to articles. Add relevant dates to reports, videos, audio recordings, datasets, testimonials, case studies, photographs and downloadable files.

Why This Rule Exists

Many media and document types lose meaning when their time context is missing.

A testimonial saying:

This service transformed our business.

may sound current, but it could have been given eight years ago.

A video describing government rules may still look professional even though the rules have changed.

A dataset without a period may show valid numbers, but nobody knows whether they represent 2023, 2025 or 2026.

A case study may describe costs that are no longer realistic.

A photograph may show a project at the beginning, middle or end of implementation. Without a date, its evidentiary value is reduced.

What Most Programmers Do

Dates are added to blog posts but omitted from other content types.

The upload date is sometimes displayed even when it is not the date the content was created.

For example, a video recorded in 2022 but uploaded to a redesigned website in 2026 may incorrectly appear to be a 2026 video.

Better Practice

Select date fields according to the content type.

For Reports

Show:

• publication date,

• reporting period,

• revision date,

• version number.

Example:

Report Published: 30 June 2026

Reporting Period: April 2025–March 2026

Version: 1.0

For Videos

Show:

• recording date,

• publication date,

• last transcript or information review date where relevant.

Example:

Recorded: 14 February 2025

Published: 2 March 2025

Information reviewed: 10 July 2026

For Datasets

Show:

• period covered,

• last data point,

• date of release,

• date of revision.

Example:

Data Period: January 2020–June 2026

Last Data Point: June 2026

Released: 15 July 2026

For Testimonials

Show:

• date or at least year,

• relationship to the organisation,

• relevant project or service.

Example:

“The new drying process reduced our losses significantly.”

— ABC Foods, Heat-Pump Drying Project, 2024

For Case Studies

Show:

• project period,

• date prepared,

• date reviewed.

Example:

Project Period: August 2024–March 2025

Case Study Published: May 2025

Results Reviewed: June 2026

For Photographs

Where context matters, record:

• date taken,

• location,

• event or project,

• photographer or source.

Example:

Tomato grading line during commissioning, Jaipur, 18 January 2026.

Programming Impact

This requires:

• content-type-specific date fields,

• media metadata,

• document metadata,

• dataset fields,

• template variation,

• and correct search and filtering.

 ________________________________________

Rule 5.6; Use Dates That Humans and Machines Can Both Understand

The Rule

Display dates clearly for people while storing and publishing them in standard machine-readable formats.

Why This Rule Exists

A human reader may understand:

18 July 2026

But software systems require dates in consistent technical formats.

Ambiguous formats can create errors.

For example:

04/05/2026

Does this mean:

• 4 May 2026, or

• 5 April 2026?

The answer depends on the country and system convention.

Machine-readable dates should therefore use a standard, unambiguous format.

A programmer must also distinguish between a date and a timestamp.

A date may be:

18 July 2026

A timestamp records the precise date, time and time zone:

2026-07-18T14:30:00+05:30

The second form tells the system that the event occurred at 2:30 p.m. in the Indian time zone.

What Most Programmers Do

Dates are stored as plain text.

Different editors enter them differently:

18 July 2026

18/07/26

July 18th, 2026

18-7-2026

Because the field is plain text, the system cannot reliably:

• sort the dates,

• compare them,

• filter records,

• create reminders,

• or share them with search engines and AI systems.

In other cases, the server stores time in one zone but displays it as though it belongs to another.

Better Practice

Store dates in proper date or datetime fields—not as ordinary text.

Use standard machine-readable formats behind the page, while displaying dates in a familiar local format for visitors.

For example:

Human-readable display:

18 July 2026

Machine-readable value:

<time datetime="2026-07-18">18 July 2026</time>

For a timestamp:

<time datetime="2026-07-18T14:30:00+05:30">

  18 July 2026, 2:30 p.m. IST

</time>

For structured article information, the system should distinguish between:

datePublished

dateModified

The published date should represent first publication.

The modified date should represent the latest meaningful editorial revision.

Example

{

  "datePublished": "2025-03-12",

  "dateModified": "2026-07-18"

}

The visible page should show the same information:

Published: 12 March 2025

Last Updated: 18 July 2026

The visible and machine-readable dates should not contradict each other.

Programming Impact

This affects:

• database field types,

• time-zone handling,

• structured data,

• APIs,

• sorting,

• filtering,

• scheduled publishing,

• and system integrations.

________________________________________ 

Rule 5.7; Flag Outdated Content Instead of Silently Leaving It Online

The Rule

When information may no longer be current, clearly warn the reader, update it, archive it or redirect them to a newer resource.

Why This Rule Exists

Old content is not always useless.

A report from 2018 may have historical value. An earlier policy may help explain how regulation evolved. An old case study may still provide useful learning.

The problem arises when historical content is presented as current information.

Silently leaving it online can mislead:

• visitors,

• students,

• researchers,

• search engines,

• and AI systems.

Deleting it is not always the right answer either. Deletion may destroy historical evidence, break links and remove useful context.

The better response depends on the type of content.

What Most Programmers Do

Old pages remain online without warning.

Visitors discover them through search engines and assume they are current.

Alternatively, old pages are deleted without redirects, producing “Page Not Found” errors.

Sometimes the old information is silently replaced, removing the historical record.

Better Practice

Provide clear status labels.

Possible labels include:

Current

Under Review

Outdated—Retained for Reference

Archived

Superseded by a Newer Version

Withdrawn

Example 1: Superseded government guideline

This page is archived.

It describes guidelines applicable until 31 March 2025. For current guidelines, see the 2026 programme page.

Example 2: Old cost estimate

Cost Warning:

These estimates were prepared in August 2023 and have not been revised for current machinery and energy prices.

Example 3: Historical case study

Historical Case Study:

This project was implemented between 2017 and 2019. The results remain useful for historical learning, but the costs and regulations should not be treated as current.

Where a newer page exists, provide a clear link to it.

Where information may be dangerous or materially misleading, consider removing it from normal navigation while retaining it in a controlled archive.

Programming Impact

This requires:

• content-status fields,

• warning banners,

• archive templates,

• replacement-page links,

• redirects,

• search filtering,

• and rules for indexing archived content.

________________________________________ 

Rule 5.8; Build Content Review into the Website System

The Rule

Do not wait for someone to remember that content has become old. Create review dates, reminders and responsibility assignments within the CMS.

Why This Rule Exists

Content freshness cannot depend entirely on human memory.

A website may contain hundreds or thousands of pages. Different pages become outdated at different speeds.

A history article may remain accurate for many years.

A product price may become outdated within weeks.

A government-scheme page may require review whenever regulations change.

A staff profile may become inaccurate when the employee leaves.

A programmer should therefore allow the organisation to define how frequently different types of content must be reviewed.

What Most Programmers Do

The CMS records when a page was published, but not when it should be checked again.

No person is assigned responsibility.

Old pages are discovered only when:

• a visitor complains,

• a link breaks,

• a regulation changes,

• or someone happens to notice the problem.

Better Practice

Add fields such as:

• content owner,

• last reviewed date,

• next review date,

• review frequency,

• review status,

• and reviewer comments.

Example

Content Owner: Agriculture Advisory Team

Last Reviewed: 18 July 2026

Next Review Due: 18 January 2027

Review Frequency: Every six months

Status: Current

The system may send reminders:

“The page ‘Organic Certification Requirements’ is due for review in 15 days.”

Review frequency should depend on the nature of the content.

Completing a review does not necessarily mean changing the content.

An expert may review the page and conclude:

The information remains accurate. No revision required.

The system may then update the Last Reviewed date without changing the Last Updated date.

This distinction is important.

Example

Published: 12 March 2025

Last Updated: 18 July 2026

Last Reviewed: 15 January 2027

Review Result: No changes required.

The page was examined in January 2027, but its information had not changed since July 2026. Therefore, the update date remains July 2026.

Programming Impact

This influences:

• CMS workflow,

• scheduled reminders,

• user roles,

• dashboards,

• notification systems,

• content ownership,

• review queues,

• and freshness reporting.

 ________________________________________

Rule 5.9; Never Manufacture Freshness

The Rule

Do not change dates, republish old content or create automatic update signals merely to make a website appear more current.

Why This Rule Exists

Freshness is valuable only when it is truthful.

Artificially changing dates may temporarily make a page look recent, but it damages trust when the reader discovers that the information itself is old.

AI systems may also repeat outdated figures while believing they came from a recently updated source.

Examples of manufactured freshness include:

• changing the date every time the page loads,

• automatically setting all pages to the current year,

• republishing an old article without reviewing it,

• displaying the date of website migration as the publication date,

• or updating the “Last Modified” field after a purely technical change.

What Most Programmers Do

During website migration, old pages are imported into a new CMS. The import date becomes the publication date for every page.

An article originally written in 2018 may then appear as though it was published in 2026.

Some templates display the current year automatically beside old content, even when the content has not been reviewed.

Better Practice

Preserve historical dates during migration.

Where the original date is unknown, say so honestly rather than inventing one.

Possible display:

Originally published: Date unavailable

Migrated to current website: 10 June 2026

Content reviewed: 15 July 2026

If an old article is substantially rewritten, the organisation may choose to publish it as a new article. In that case:

• preserve or archive the old version,

• explain that the new article replaces it,

• and avoid silently converting the old record into something new.

Programming Impact

This affects:

• migration scripts,

• imported data,

• automated date fields,

• publication workflows,

• archive integrity,

• and organisational trust.

 ________________________________________

A Practical Date Structure for a Major Webpage

A well-managed informational page may display:

Published: 12 March 2025

Last Updated: 18 July 2026

Updated for: New government guidelines and revised cost figures

Last Reviewed: 15 January 2027

Review Result: Information remains current

Next Review Due: 15 July 2027

Content Status: Current

Not every page needs to display every field publicly.

However, the CMS should be capable of maintaining them.

For a normal article, the public display may be limited to:

Published: 12 March 2025

Last Updated: 18 July 2026

Updated for: Revised cost figures and new government guidelines.

The remaining information may stay within the administrative system.

 ________________________________________

Suggested CMS Date Fields

A programmer designing the CMS should consider providing the following fields:

The programmer should not necessarily show all these fields to visitors. Their purpose is to create an honest and manageable freshness system.

 ________________________________________

Chapter Summary

Dates are not small labels added beside an article title.

They tell visitors when information originated, whether it has changed, whether it has been reviewed and whether it should still be trusted.

A properly designed website distinguishes between:

• publication,

• meaningful revision,

• technical modification,

• formal review,

• and future review.

It preserves the original publication date, explains substantial updates, maintains revision history for important documents and attaches proper time context to reports, datasets, videos, testimonials, photographs and case studies.

It also warns visitors when information is outdated instead of silently presenting old content as current.

Most importantly, it does not manufacture freshness by changing dates without changing or reviewing the information.

The programmer cannot personally verify every fact on the website. But the programmer can create a system that makes responsibility, revision and freshness visible.

In the AI era, this becomes even more important. A clearly dated and honestly maintained page helps both people and machines distinguish current knowledge from historical information.

A good website should therefore answer not only:

What does this page say?

It should also answer:

When was it written?

When did it last meaningfully change?

Why was it changed?

Has someone checked it recently?

Can it still be relied upon today?