Date & Time · Validator
RFC 3339 timestamp validator.
Check a date-time against the RFC 3339 grammar, see exactly which rule failed, and get the normalised UTC time, epoch milliseconds and offset. Runs in your browser; nothing is sent anywhere.
Input
Result
Enter a timestamp and press Check.
How RFC 3339 timestamps are checked
RFC 3339 section 5.6 defines date-time = full-date "T" full-time. The full-date is YYYY-MM-DD with a 4-digit year; full-time is HH:MM:SS, an optional fraction (. and one or more digits) and a mandatory offset, either Z or +HH:MM / -HH:MM. For example, 1996-12-19T16:39:57-08:00 is the same instant as 1996-12-20T00:39:57Z.
Ranges: month 01-12, hour 00-23, minute 00-59, second 00-60. The day must exist in that month and year, so 2000-02-29 is valid, 1900-02-29 and 2026-04-31 are not. Hour 24 is not allowed. Offset hours are 00-23 and offset minutes 00-59.
Leap seconds: second 60 is only valid at the very end of a UTC June 30 or December 31, that is 23:59:60Z, or the same instant written with an offset such as 15:59:60-08:00. Anywhere else it fails. Epoch values fold the leap second into the next second, as POSIX time does.
Normalised UTC, epoch and offset: a valid value is converted to UTC, and the offset is shown in minutes. The epoch in milliseconds truncates any digits past the third of the fraction. -00:00 is valid and means the UTC time is known but the local offset is not.
RFC 3339 vs ISO 8601
RFC 3339 is a profile of ISO 8601 meant for Internet protocols, so it is narrower. Compared with ISO 8601 as a whole, it requires an explicit offset (a local time with no offset is fine in ISO 8601, not here), a 4-digit year, the extended format with hyphens and colons, and all three of hours, minutes and seconds. It has no week dates (2026-W40-2), no ordinal dates (2026-272), no comma decimal separator and no durations or intervals. It also forbids hour 24. Separating date and time with a space is only mentioned in a NOTE as something an application may choose for readability; this page rejects it unless you tick the box.
Every valid RFC 3339 timestamp is valid ISO 8601, but not the other way round. To convert a valid result to seconds since 1970, or the reverse, use the Unix Timestamp Converter.
Sources: RFC 3339, Date and Time on the Internet: Timestamps (RFC Editor), sections 5.6 (grammar), 5.7 (restrictions and leap seconds) and 5.8 (examples); and the WHATWG HTML Standard, common microsyntaxes, "valid global date and time string", used as an independent check. It agrees on the year, month, day-of-month, time and offset ranges, but is looser (optional seconds, offset without a colon) and stricter (no leap second, no -00:00) in places, so RFC 3339 is the rule applied here.
Frequently asked questions
Is "2026-09-29T12:00:00" valid RFC 3339?
No. RFC 3339 requires a UTC offset, so the value needs a trailing Z or +/-HH:MM. ISO 8601 alone would accept it as a local time.
Can I use a space instead of T?
The grammar says T. Section 5.6 has a NOTE that applications may choose a space for readability, so some systems accept it, but it is not the RFC 3339 format. Tick the box to allow it.
Are lower-case t and z allowed?
Yes, the ABNF is case-insensitive, but RFC 3339 says applications that generate the format should use upper case.
Why is the second 60 rejected on some dates?
A leap second can only occur at 23:59:60 UTC on June 30 or December 31. Any other time with second 60 fails. This page checks that shape; it does not know which leap seconds were actually announced.
Format check only
This tool checks that a string follows the RFC 3339 date-time grammar and calendar rules. It cannot tell you whether the instant is real, was recorded by any system, or whether a leap second was ever inserted on that date. Nothing you type is stored or sent anywhere.