Ward CAD 2026 Mineral ZIP Date Register: March 26, July 16, and July 23

Direct answer for mineral owners

The Ward CAD 2026 mineral ZIP central directory groups its seven entries on March 26, July 16, and July 23, 2026. File-number order is not date order. Each entry has a conventional DOS date/time and a 0x5455 extended timestamp field, but neither representation establishes publication, certification, creation, update, effective, delivery, or data-as-of chronology.

Key takeaways for mineral owners

• The official Ward page links the exact 2026 certified mineral appraisal roll ZIP reviewed here.
• The seven central-directory entries fall on three calendar dates: March 26, July 16, and July 23, 2026.
• Filename prefixes 1 through 7 do not sort chronologically: member 2 is the earliest date and member 4 is the latest date.
• Each entry contains a conventional MS-DOS date/time and a five-byte 0x5455 extended timestamp field.
• Archive-entry timestamps do not establish publication, certification, creation, update, effective, filing, delivery, approval, or data-as-of chronology.

Archive metadata, not business chronology. This page inventories central-directory fields in one exact Ward CAD ZIP retrieval. It does not establish when Ward CAD published, certified, created, updated, approved, received, delivered, filed, or relied on a member; identify a data-as-of date; interpret member payloads; establish ownership, title, acreage, production, appraisal, tax, private mineral-rights value, offer quality, or legal effect; or recommend a transaction. Any later MRX assessment is directional only and is not an appraisal performed by a state-licensed or state-certified real estate appraiser. This page is not legal, tax, title, accounting, engineering, or investment advice. MRX provides educational information and resources only and does not buy mineral rights.

The direct answer is: the seven entries in the Ward CAD 2026 mineral ZIP central directory fall on three calendar dates: March 26, July 16, and July 23, 2026. Member 2 carries the March 26 date. Members 1, 3, 5, 6, and 7 carry July 16 dates. Member 4 carries the July 23 date.

The filename prefixes are not a chronological sequence. The archive also carries two timestamp representations for every entry: conventional MS-DOS date/time fields and a five-byte 0x5455 extended timestamp field. Those fields are source-control metadata. They do not prove a publication, certification, creation, update, effective, filing, delivery, upload, approval, or data-as-of chronology.

Start with the exact publisher and archive

The Ward CAD Data and Records page displays a 2026 Certified Mineral Appraisal Roll (Zip) link. The exact Ward CAD 2026 ZIP retrieved through that route is the source container for this date register.

Control	Observed value
Publisher page retrieved	August 31, 2026
Publisher-page bytes	74,781
Publisher-page SHA-256	c9e483ed6ce3d0f66869acc15393212782866f0bd03c315cd4429b8c8c68921f
ZIP retrieved	August 31, 2026
ZIP bytes	35,266,126
ZIP SHA-256	7993b427ee51193ce86d5490102054e2e30e26f5811cacfd3791819803d07752
Central-directory entry count	7
Uncompressed bytes in directory	465,352,945
Compressed bytes in directory	35,264,682

The publisher-page label describes the linked archive at that route. It does not assign a publication or certification date to each inner member. The archive hash identifies the exact outer byte object reviewed; it does not certify the meaning of its internal timestamps.

The seven-member date register

The following table transcribes central-directory metadata without opening a member payload for content analysis. Times come from ZipInfo 3.00 in an America/Los_Angeles environment. “UT local” and “UT UTC” are two renderings of the same extended modification value. “DOS” is the conventional MS-DOS representation stored with the entry.

Member	Central-directory name	Uncompressed bytes	DOS representation	UT local	UT UTC
1	1. MINERAL APPRAISAL ROLL.PDF	13,067,707	Jul 16, 18:52:44	Jul 16, 16:52:44	Jul 16, 23:52:44
2	2. MINERAL FILE LAYOUT.pdf	46,370	Mar 26, 17:41:48	Mar 26, 15:41:48	Mar 26, 22:41:48
3	3. MINERAL DATA FLAT TEXT FILE.TXT	190,783,867	Jul 16, 18:47:06	Jul 16, 16:47:07	Jul 16, 23:47:07
4	4. MINERAL DATA CSV FILE.CSV	252,451,081	Jul 23, 14:31:30	Jul 23, 12:31:31	Jul 23, 19:31:31
5	5. MINERAL RECAP.PDF	5,578	Jul 16, 18:51:16	Jul 16, 16:51:17	Jul 16, 23:51:17
6	6. YR X YR APPRAISALS.PDF	5,844,383	Jul 16, 17:08:02	Jul 16, 15:08:03	Jul 16, 22:08:03
7	7. MASTER INVENTORY LISTING.PDF	3,153,959	Jul 16, 17:08:16	Jul 16, 15:08:16	Jul 16, 22:08:16

The year for every row is 2026. The table keeps each representation visible instead of silently choosing one clock time. It also preserves the one-second differences that can appear between a DOS value and the extended value.

Why the clock times differ

The PKWARE ZIP APPNOTE page identifies APPNOTE as the maintained ZIP format specification. In the exact APPNOTE 6.3.10 text retrieved for this review, section 4.4.6 says the conventional date and time fields use standard MS-DOS format, differ from UTC, and use two-second precision. Section 4.6.1 maps header ID 0x5455 to the extended timestamp field.

The Ward archive’s verbose central-directory report shows both fields on every entry. ZipInfo renders the extended timestamp in the current local environment and in UTC. That is why one entry can show three clock readings without representing three separate events.

Member 1 is the clearest example:

• DOS representation: July 16 at 18:52:44;
• UT displayed locally in America/Los_Angeles: July 16 at 16:52:44;
• UT displayed as UTC: July 16 at 23:52:44.

The correct citation must name the tool, environment, and representation. Saying only “the file date is 6:52 p.m.” would hide which stored field and rendering produced that time.

The one-second differences on members 3 through 6 are also expected evidence to preserve, not round away. The conventional DOS format has two-second precision. The extended field can retain an odd-numbered second. This explains a format-level precision difference; it does not explain who set a timestamp or why.

Number order is not date order

Reading the filename prefixes from 1 through 7 produces a convenient inventory. It does not produce the metadata-date order.

If the rows are grouped by the supported calendar date, the sequence is:

1. March 26: member 2;
2. July 16: members 6, 7, 3, 5, and 1 when sorted by the displayed UT value;
3. July 23: member 4.

That reordered list is a sort of archive metadata, not a reconstruction of the publisher’s workflow. The sources do not state that the earliest timestamp marks the first created file, that the latest timestamp marks a later correction, or that the numbered prefixes describe processing order.

Several explanations could produce a mixed-date archive: preserving prior file times, exporting components at different moments, copying files between systems, or assembling a container from existing objects. None is selected here because the reviewed sources do not identify the archive creator, the commands used, the source systems, or the intended chronology.

What the three dates support

The three date groups support a small set of source-control statements:

• the exact retrieved ZIP contains seven named entries;
• those entries carry three distinct calendar dates in the displayed metadata;
• member 2 is the only March 26 row;
• member 4 is the only July 23 row;
• five members carry July 16 rows;
• numeric filename order does not match calendar-date order;
• every row includes both the conventional DOS fields and a 0x5455 extended timestamp field.

These observations can help a researcher record which exact archive was reviewed, notice a later byte change, and avoid collapsing multiple timestamp representations into one undocumented value.

What the dates do not support

Archive metadata should not be promoted into a business fact without another source that defines the relationship.

Observed archive field	Supported statement	Do not infer
Three calendar dates	Three date groups appear in the exact retrieved archive	Three publication or certification events
Filename prefixes 1 through 7	Seven labels define a member inventory	Creation, review, approval, or delivery order
DOS date/time	Conventional ZIP date/time representation	UTC, uploader timezone, publisher action, or data-as-of time
0x5455 extended timestamp	Extended modification value is present	Creator identity, legal status, appraisal date, or public release
July 23 on member 4	Member 4 has the latest calendar date in this register	A correction, replacement, final version, or later certified roll
March 26 on member 2	Member 2 has the earliest calendar date in this register	Original authorship, first publication, or continuing applicability

The word “Certified” appears in the publisher’s link label for the ZIP. That label does not convert every inner timestamp into a certification timestamp. A member name can identify a format or apparent subject, but its payload and legal or appraisal meaning remain outside this article.

Privacy and payload boundary

The archive includes filenames suggesting a roll PDF, text data, CSV data, recap, appraisal comparison, and inventory listing. This date register does not use those names as permission to inspect or republish their contents.

No member payload was extracted to disk, displayed, parsed for content, searched, sampled, summarized, or reproduced for this article. No owner name, account, address, email, property identifier, legal description, value field, production figure, or row was collected. The only member-level evidence used is the central-directory metadata above.

That boundary matters because a timestamp question can be answered without exposing person-level or property-level information. If a later job requires a payload field, it should begin as a separate, deliberately scoped review with privacy, relevance, and citation controls.

Keep adjacent article jobs separate

The Ward CAD 2026 mineral recap owns the district-row item and gross-value aggregate. This page does not repeat those totals or use them to discuss private mineral-rights value.

The Ward and Loving shared layout-PDF comparison owns the byte identity of one selected inner PDF across two publisher archives. This page does not reopen that PDF, repeat its internal map, or compare its contents.

The Karnes seven-member index and Howard 16-member index own different publisher routes, archive hashes, member sets, and broader container-inventory jobs. Article 310 is narrower: it explains the Ward date groups, the two timestamp representations, and the limits on chronology claims.

Claim, evidence, and limit map

Claim ID	Evidence role	Supported statement	Limit
C310-01	PUBLISHER-ROUTE	Ward CAD displays the 2026 Certified Mineral Appraisal Roll ZIP link.	Does not date or validate an inner member
C310-02	SOURCE-HASH	The exact ZIP has 35,266,126 bytes and the recorded complete-file SHA-256.	Does not establish who created or uploaded it
C310-03	DIRECTORY-INVENTORY	The central directory contains seven entries.	Does not establish seven owners, accounts, properties, or records
C310-04	DATE-GROUP	Entry calendar dates group into March 26, July 16, and July 23, 2026.	Does not establish business chronology
C310-05	FORMAT-OBSERVATION	Every row has conventional DOS date/time and a five-byte 0x5455 timestamp field.	Does not identify which application wrote either field
C310-06	TOOL-RENDERING	ZipInfo 3.00 renders DOS, UT-local, and UT-UTC clock values.	Another tool may display or label time differently
C310-07	ORDER-BOUNDARY	Numeric filename order differs from metadata-date order.	Does not reveal creation, review, export, approval, or upload order
C310-08	EXCLUDED-SCOPE	Member payload content is not used.	No content, ownership, appraisal, tax, or value conclusion

Stable claim IDs make a later update easier to audit. If the publisher serves a different ZIP, preserve the new retrieval date, byte count, complete-file hash, tool version, environment, and representation before revising a row.

A citation-ready answer

In the Ward CAD 2026 mineral ZIP retrieved August 31, 2026, the seven central-directory entries group on March 26, July 16, and July 23, 2026. Member-number order is not date order. Each entry contains conventional DOS date/time fields and a 0x5455 extended timestamp field. These are archive-entry metadata and do not establish publication, certification, creation, update, effective, delivery, or data-as-of chronology.

This answer is intentionally narrow. It states the archive identity, the date groups, the dual representation, and the inference stop without implying a private-value or legal conclusion.

Questions to ask before relying on a date

If a timestamp matters to a property, appraisal, tax, title, or transaction question, ask for evidence that defines the date’s role:

1. Which exact source object and SHA-256 are being cited?
2. Is the quoted value DOS, UT local, or UT UTC?
3. Which tool, version, and local environment rendered it?
4. Does a publisher document define the field as a publication, certification, effective, or data-as-of date?
5. Is there a later official release, notice, or correction that supersedes the archive?

For a Texas appraisal or tax question, use the Texas Comptroller property-tax contact page to identify the appropriate state or local route. That page does not interpret this archive or answer a property-specific legal or tax question.

For a broader county context, open the Texas mineral-rights guide. For a specific transaction question, book a confidential review and keep archive metadata separate from title, ownership, appraisal, tax, private value, and offer evidence.

Frequently asked questions

What calendar dates appear in the Ward CAD 2026 mineral ZIP?

ZipInfo 3.00 groups member 2 on March 26, members 1, 3, 5, 6, and 7 on July 16, and member 4 on July 23, 2026. Those dates are archive-entry metadata.

Are members 1 through 7 arranged by date?

No. Member 2 has the earliest calendar date, five members have July 16 dates, and member 4 has the latest calendar date. The numeric prefixes are inventory labels, not proven chronology.

Why does one member show more than one clock time?

Each entry has conventional DOS date/time fields and a 0x5455 extended timestamp field. ZipInfo 3.00 can display the extended value in the local America/Los_Angeles environment and as UTC. Quote the representation with the time.

Do the timestamps prove when Ward CAD published or certified each file?

No. The reviewed sources do not define the fields as publication, certification, creation, update, effective, filing, delivery, upload, approval, or data-as-of dates.

Did MRX inspect owner or property records for this article?

No member payload was extracted to disk, displayed, parsed for content, searched, sampled, summarized, or reproduced. The article uses central-directory metadata only.

Sources reviewed for this article

• Ward CAD Data and Records, accessed August 31, 2026.
• Ward CAD 2026 Certified Mineral Appraisal Roll ZIP, accessed August 31, 2026.
• PKWARE ZIP APPNOTE, accessed August 31, 2026. Exact APPNOTE 6.3.10 text used for sections 4.4.6 and 4.6.1 was hash-locked in the review packet.
• Texas Comptroller property-tax contacts, accessed August 31, 2026.

Frequently asked questions

What calendar dates appear in the Ward CAD 2026 mineral ZIP?

ZipInfo 3.00 groups member 2 on March 26, members 1, 3, 5, 6, and 7 on July 16, and member 4 on July 23, 2026. These are archive-entry metadata dates.

Are members 1 through 7 arranged by date?

No. Member 2 carries the earliest calendar date, five other members carry July 16 dates, and member 4 carries the latest calendar date. The numeric prefixes are labels, not proven chronology.

Why does one member show more than one clock time?

The archive carries conventional DOS date/time fields and a 0x5455 extended timestamp field. ZipInfo can display the extended value in the local environment and in UTC, so every quoted time must name its representation.

Do the timestamps prove when Ward CAD published or certified each file?

No. The reviewed sources do not define the fields as publication, certification, creation, update, effective, filing, delivery, upload, approval, or data-as-of dates.

Did MRX inspect owner or property records for this article?

No member payload was extracted to disk, displayed, parsed for content, searched, sampled, summarized, or reproduced. The article uses central-directory metadata only.

Sources reviewed for this article

• Ward CAD Data and Records page (accessed 2026-08-31)
• Ward CAD 2026 Certified Mineral Appraisal Roll ZIP (accessed 2026-08-31)
• PKWARE ZIP APPNOTE page (accessed 2026-08-31)
• Texas Comptroller property-tax contacts (accessed 2026-08-31)