Skip to content

Main content

iCalendar Basic Date Token Parser

Parse and calendar-validate one strict YYYYMMDD iCalendar basic date, including Gregorian leap rules; no timestamp conversion.

Loading tool…

Description

Parse and calendar-validate one strict YYYYMMDD iCalendar basic date, including Gregorian leap rules; no timestamp conversion.

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

Parse and calendar-validate one strict YYYYMMDD iCalendar basic date, including Gregorian leap rules; no timestamp conversion.

When to use this tool

Use this tool to parse and calendar-validate one strict YYYYMMDD iCalendar basic date, including Gregorian leap rules; no timestamp conversion.

How to use the tool and how it works

  1. Enter token using the field definitions below.
  2. Run the operation. Correct input errors before interpreting an output.
  3. Read result.year, result.month, result.day. Use the ordering, boundary rules and absence conditions described below.

Require YYYYMMDD, validate Gregorian year 1–9999 and month/day including leap years, then return numeric date components.2

Input fieldMeaning and unitsAccepted input
tokenOne complete basic date/time or duration token under the stated operation.Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies.
Output fieldInterpretation
resultObject containing the named fields below.
result.yearValidated Gregorian year.
result.monthValidated Gregorian month.
result.dayValidated Gregorian day of month.
json
{
  "input": {
    "token": "20240229"
  },
  "output": {
    "result": {
      "year": 2024,
      "month": 2,
      "day": 29
    }
  }
}

Limitations and assumptions

  • This parses a date only, not a timestamp, local timezone or jurisdiction-specific calendar.
  • 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

  1. RFC 5545: Internet Calendaring and Scheduling Core Object Specification — RFC Editor

  2. Tool behavior and example: iCalendar Basic Date Token Parser — tool.io

Similar or alternative tools