Description
Check explicit date/floating/UTC/zoned value-kind compatibility and exact zone-label agreement; not zone equivalence, chronology or complete iCalendar component validation.
iCalendar separates content-line framing, property values, parameters and component nesting. TEXT escaping protects separators, while line folding is based on encoded octets. DATE, floating time, UTC and named-zone representations carry different information; a token-level operation does not resolve a timezone or expand recurrence rules.1
Check explicit date/floating/UTC/zoned value-kind compatibility and exact zone-label agreement; not zone equivalence, chronology or complete iCalendar component validation.
When to use this tool
Use this tool to check explicit date/floating/UTC/zoned value-kind compatibility and exact zone-label agreement; not zone equivalence, chronology or complete iCalendar component validation.
How to use the tool and how it works
- Enter startKind, endKind, startZone, endZone using the field definitions below.
- Run the operation. Correct input errors before interpreting an output.
- Read result.compatible. Use the ordering, boundary rules and absence conditions described below.
Require startKind and endKind from date, floating, utc or zoned. Report compatibility only for equal kinds and, for zoned values, equal nonempty zone strings.2
| Input field | Meaning and units | Accepted input |
|---|---|---|
| startKind | Exact kind: date, floating, utc or zoned. | Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies. |
| endKind | Exact kind: date, floating, utc or zoned. | Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies. |
| startZone | Nonempty zone label when startKind is zoned; not looked up in a timezone database. | Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies. |
| endZone | Nonempty zone label when endKind is zoned; not looked up in a timezone database. | Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies. |
| Output field | Interpretation |
|---|---|
| result | Object containing the named fields below. |
| result.compatible | Whether supplied kinds agree, including equal nonempty zone labels for zoned values. |
{
"input": {
"startKind": "date",
"endKind": "utc",
"startZone": "",
"endZone": ""
},
"output": {
"result": {
"compatible": false
}
}
}Limitations and assumptions
- Zone labels are compared exactly without timezone lookup or instant conversion; unused zone strings do not affect other kinds.
- Content spans use zero-based UTF-16 offsets; fold limits use UTF-8 bytes including the continuation space. Token helpers handle the stated subset only, without a timezone database, recurrence engine or calendar import.
- Every declared top-level input field is required and unexpected fields are rejected. Ordinary strings are limited to 8,192 UTF-16 code units and lists to 128 entries, with tighter operation-specific bounds where stated. JSON text has bounded nesting and node counts.
- Numeric outputs must be finite and no larger in absolute magnitude than the safe-integer limit; operations returning exact large integers use decimal text. Positions are zero-based and spans end exclusively unless the operation explicitly states a different convention.
Alternative or Complementary methods
Keep content-line syntax, value escaping and timezone interpretation separate. Use a complete iCalendar implementation for recurrence expansion, timezone transitions and property-specific validation.
References
Similar or alternative tools
- iCalendar Basic Date Token Formatter
Format a validated proleptic Gregorian iCalendar basic date with year 1–9999; no time zone or floating date-time inference.
- iCalendar Basic Date Token Parser
Parse and calendar-validate one strict YYYYMMDD iCalendar basic date, including Gregorian leap rules; no timestamp conversion.