Verifying birth data

A converted time needs a label of its own

A local clock reading and a converted time are not interchangeable entries. If the converted value replaces the original, a later user or tool may apply the same adjustment again. Keep what the source actually said beside a separate record of each conversion and its assumptions.

Consider a purely arithmetic example with no birth date: a local reading of 10:00 has already been verified as using UTC+08:00. Subtracting eight hours gives 02:00 UTC. The verified offset is a premise of the example, not a fact inferred from an unspecified city. A solar-time adjustment is a different operation and must not be folded into the zone offset and subtracted twice.

The IANA Time Zone Database represents local-time history for representative locations and is updated for changes in boundaries, offsets and daylight-saving rules. Its purpose highlights why today's offset should not be copied across every historical date. Record the zone and data version used, and leave unresolved historical details visible.

Reconstruct the source before completing the form

Identify whether the date is Gregorian or belongs to another calendar. For a Chinese lunar date, a leap-month indication may be essential. A family reference to a birthday is not enough to determine the calendar without clarification. Preserve the original notation before consulting a conversion source.

The Hong Kong Observatory provides annual Gregorian–lunar conversion tables. They are a source for calendar checking, not a universal record of civil-time rules for every location. Their notes also describe boundary uncertainty for certain distant moon-phase or solar-term dates close to midnight. Read the scope of the table rather than treating every displayed date as a substitute for all timing questions.

For the clock time, establish the notation and precision actually supported: 12-hour or 24-hour format, an exact written value or an approximate recollection. Do not turn “about” into an exact minute merely because a form accepts minutes. A default value should retain its status as a placeholder, not become a verified fact through repeated use.

A region is not its administrative capital

Resolve ambiguous names and historical place names with enough higher-level context to identify the intended location. Administrative labels differ between countries; a word such as county does not establish an identical level everywhere. Do not guess a finer place simply to make every field look complete.

If the supported input is a city-level or county-level region, preserve that region. Do not silently replace it with its capital, administrative seat or a town within it. The coordinate provenance should match the named area. A more specific known place can be handled as that place, while an unresolved country or broad region should remain a request for more information rather than a guessed coordinate.

Collect only information relevant to the calculation. A full address, identity number or relatives' details does not resolve a calendar or time-zone ambiguity. For a teaching discussion, remove identifying material and retain the setting or conversion issue that actually needs inspection. No personal document needs to be made public for the process described here.

Open the full-size diagram

Original BaZiFlow data diagram. It contains field relationships only, with no personal birth or identity information.

The four branches belong to the original record; the lower area keeps processing results distinct. This separation makes it possible to repeat a conversion without losing the evidence it started from.

Two versions are a reason to compare, not to erase

If a document and a recollection disagree, retain both with their provenance and precision. Determine what can be verified before selecting a value. Later evidence may justify a revision, but the change should state which source altered which field and when.

Do not choose a time by generating several readings and keeping the one that feels most recognisable. That is not the same kind of evidence as a contemporaneous record. If only a range can be supported, keep the range. Birth-time uncertainty across systems explains how to identify stable and variable outputs within it.

Likewise, a correction to a time conversion does not establish that the original document was wrong. It may establish only that a later processing step used an incorrect assumption. Version notes keep these different kinds of correction from being confused.

Enter the value the tool actually asks for

When a tool requests local civil time and performs the conversion itself, a pre-adjusted input can cause double processing. Check the meaning of the field and the relevant settings rather than repeatedly changing the time until an output looks familiar. If the behaviour is unclear, save the input and settings before investigating it.

The finished record may still contain confirmed fields, candidate ranges and missing information. That is a usable result. It tells the next reader which claims can be made directly and which need conditions. A precise-looking string with no provenance cannot offer the same reassurance.

Settings to check when results differ continues from this point, once the original data has been kept intact.

1. 1

   Save both values

   Record local 10:00 as the source and 02:00 UTC as the result under a verified+08:00 offset.

2. 2

   Test double processing

   Entering 02:00 into a field that expects local time and subtracts 8 h would incorrectly produce 18:00 on the preceding day.

3. 3

   Correct the input choice

   Supply 10:00 when local time is requested, while retaining the offset and result in the processing record.