Source: https://guthlabs.ai/docs/instruments/time-zone-converter/
instrument / verified-clean
# Time Zone Converter
The current ledger marks this instrument verified clean within the source-bound verification corpus.
Status: **VERIFIED_CLEAN**Lifecycle: **verified-clean**
## Inspectable records
[01**Overview**Purpose and lifecycle]()[02**Mechanism**Method and assumptions]()[03**Implementation**Binding and validation]()[04**Qualification**Evidence and errata]()
## Ledger state
The current ledger marks this instrument verified clean within the source-bound verification corpus.
**Area**: Everyday & Life
**Tranche**: tranche-7
**Evidence ID**: t7-039
**Ledger rows**: 1
No ledger note is attached.
## Review findings
The core algorithm is standard and the four vectors are computable from their supplied IANA table fragments. Verdict is NEEDS_REVIEW because the spec omits the mandatory date field in its input description, gives no policy for nonexistent or repeated local times, and does not identify the tzdata version or output-format contract.
### Formula and scope findings
- The stated method is fundamentally correct: resolve the source zone's UTC offset from the IANA tz database, convert the source civil time to UTC, then apply the target zone's offset.
- The formula description is incomplete unless the input includes a calendar date and the exact local-time disambiguation policy for DST fall-back and spring-forward transitions.
- DST must not be implemented as a generic one-hour toggle; IANA transition rules and historical offsets must be used for each named zone.
- The required tzdata/IANA database version is unspecified, so results can vary across operating-system releases, especially for historical or recently changed time-zone rules.
### Unit assumptions
- Inputs are Gregorian civil date-times in ISO 8601 local time, with no leap-second value such as 23:59:60.
- UTC offsets in the reference data are seconds east of UTC; arithmetic converts them to minutes or hours only for display.
- The source local time is assumed to be valid and unambiguous unless an explicit overlap/gap policy is supplied.
- The vectors use IANA tzdata 2024a rules and the proleptic Gregorian calendar.
- Output formatting is assumed to be local ISO 8601 date-time plus the resolved UTC offset and abbreviation.
## Boundary hardening
### Recorded hazards
- A local source time during a spring-forward gap, such as 2024-03-10 02:30 in America/New_York, does not exist; the instrument must reject it or document a defined adjustment.
- A local source time during a fall-back overlap, such as 2024-11-03 01:30 in America/New_York, occurs twice; the instrument must require a fold/occurrence choice or document its default.
- Missing source date makes DST-aware conversion impossible or ambiguous.
- Named zones, fixed offsets, and abbreviations are not interchangeable; abbreviations such as CST and IST are ambiguous and should not be accepted as zone identifiers without clarification.
- If the native operating-system tz database differs from the documented version, historical and future results may differ; the app should expose or document the data source/version.
- Conversion across date boundaries must preserve the date, not only the clock time.
- Invalid IANA zone identifiers and malformed local date-times require explicit validation and error handling.
## Errata and corrections
No applied erratum is attached to this unique-name record.
## Inspectable example
4 review vectors are recorded. One source-bound sample is shown below.
````
{
"inputs": {
"source_time": "2024-07-01T12:00:00",
"source_zone": "America/New_York",
"target_zones": [
"Europe/London"
]
},
"expected_outputs": {
"Europe/London": {
"local_time": "2024-07-01T17:00:00",
"utc_offset": "+01:00",
"abbreviation": "BST"
}
},
"reference_data": {
"source_zone_row": {
"zone": "America/New_York",
"utc_interval": "2024-03-10T07:00:00Z through 2024-11-03T06:00:00Z",
"utc_offset_seconds": -14400,
"abbreviation": "EDT",
"dst": true,
"source_convention": "IANA tzdata 2024a TZif data"
},
"target_zone_row": {
"zone": "Europe/London",
"utc_interval": "2024-03-31T01:00:00Z through 2024-10-27T01:00:00Z",
"utc_offset_seconds": 3600,
"abbreviation": "BST",
"dst": true,
"source_convention": "IANA tzdata 2024a TZif data"
}
},
"working": "New York local time = 12:00. Convert to UTC: 12:00 - (-04:00) = 16:00 UTC. Convert UTC to London: 16:00 + (+01:00) = 17:00. Therefore the result is 2024-07-01 17:00 BST."
}
````
## Related workflows
No source-defined multi-instrument workflow membership is recorded.
## Sources and evidence
These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.
- `VERIFIED_LEDGER.json ยท VERIFIED_CLEAN`
- `evidence-tranche7/tranche7-results.json`