MeridianMERIDIAN

ISO Datetime with Milliseconds (no timezone)

datetime.timestamp.iso_millisecondssince finetype v0.6.36

ISO 8601-like format with millisecond precision but no timezone indicator (e.g. 2013-06-04T01:02:03.123). Common in database exports and log files. The zoneless sibling of iso_8601_milliseconds.

Try a value

ISO Datetime with Milliseconds (no timezone)'s rule accepts it.

Reads it as 2024-03-04 05:06:07.123

Worked samples

DuckDB 1.5.5 · finetype 0.6.66

ValueAs TIMESTAMP
2013-06-04T01:02:03.1232013-06-04 01:02:03.123
2024-01-15T10:30:00.5002024-01-15 10:30:00.5
%Y
four-digit year
%m
month, two digits
%d
day of month, two digits
%H
hour, 24-hour clock
%M
minutes
%S
seconds
%g
milliseconds
Standard

Shape

Pattern
^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}$
ValueLengthShape
2013-06-04T01:02:03.12323matches
2024-01-15T10:30:00.50023matches
2013-06-04T01:02:03.1222rejected: one character short

Background

Origin

ISO 8601 is an international standard covering the worldwide exchange and communication of date and time-related data.[1] ISO 8601 is maintained by the International Organization for Standardization (ISO).[1] ISO 8601 was first published in 1988.[1] The fourth revision of the standard, ISO 8601-1:2019, was issued in February 2019.[1]

ISO 8601 writes a point in time by joining a complete date, the letter T as a delimiter, and a valid time.[1] ISO 8601 separates a time element from its decimal fraction with a decimal mark, either a comma or a dot.[1] ISO 8601 sets no limit on the number of decimal places for the decimal fraction.[1] Wikipedia's account of ISO 8601 says the number of decimal places needs to be agreed to by the communicating parties.[1] Three digits after the dot, milliseconds, is one such agreement. (Meridian's view)

Under ISO 8601, if no UTC relation information is given with a time representation, the time is assumed to be in local time.[1] Wikipedia's account of ISO 8601 says unqualified local time is ambiguous when used in communicating across different time zones.[1] Even within a single time zone, some local times are ambiguous if the region observes daylight saving time.[1] A value like 2013-06-04T01:02:03.123 is therefore a wall-clock reading to the millisecond, and the clock it was read from is not written down. (Meridian's view)

RFC 3339, Date and Time on the Internet: Timestamps, was written by G. Klyne and C. Newman.[2] RFC 3339 is dated July 2002.[2] RFC 3339 defines a date and time format for use in Internet protocols.[2] RFC 3339's grammar defines full-time as partial-time followed by time-offset, so a timestamp with no Z and no offset does not match its date-time rule.[2] RFC 3339 deems the interoperability problems of unqualified local time unacceptable for the Internet.[2]

Use

Microsoft SQL Server's CONVERT function has a style 126, labelled ISO8601, whose output is yyyy-MM-ddTHH:mm:ss.fff.[3] SQL Server's style 127, ISO8601 with time zone Z, writes yyyy-MM-ddTHH:mm:ss.fffZ.[3]

Python's isoformat() accepts timespec='milliseconds', which includes the full time but truncates the fractional second part to milliseconds.[4] Python's documentation says excluded time components are truncated, not rounded.[4] Java's LocalDateTime class does not store or represent a time-zone.[5] Java's LocalDateTime.toString() outputs the shortest ISO-8601 format that gives the full value, and uuuu-MM-dd'T'HH:mm:ss.SSS is one of those formats.[5]

In JavaScript, when the time zone offset is absent, date-time forms are interpreted as a local time.[6] Decide the zone yourself before you parse, rather than letting the local setting of whichever machine runs the code choose it for you. (Meridian's view)

Socrata's floating timestamp datatype represents an instant in time with millisecond precision and no timezone value.[7] Socrata encodes floating timestamps as ISO8601 times with no timezone offset, as in 2014-10-13T00:00:00.000.[7] Socrata says that when writing data only accuracy to the second is required, but the service will always return precision to the millisecond.[7] Socrata's documentation says datasets will either specify what timezone they should be interpreted in, or you can usually assume they are in the timezone of the publisher.[7]

Where you'll meet it

New York City's 311 Service Requests from 2020 to Present dataset returns its created_date values through the SODA API with three fractional digits and no time zone offset.[8]

Sources

  1. [1]ISO 8601secondary source
  2. [2]RFC 3339: Date and Time on the Internet: Timestampsstandard
  3. [3]CAST and CONVERT (Transact-SQL) - SQL Server | Microsoft Learndocumentation
  4. [4]datetime — Basic date and time typesdocumentation
  5. [5]LocalDateTime (Java SE 21 & JDK 21)documentation
  6. [6]Date - JavaScript | MDNdocumentation
  7. [7]Floating Timestamp Datatypedocumentation
  8. [8]311 Service Requests from 2020 to Presentdataset

Detection notes

New in v0.6.36 (spec 2026-06-19-zoneless-iso-datetime-leaves). Zoneless millisecond sibling of iso_8601_milliseconds, mirroring iso_microseconds. Distinct from iso_8601_milliseconds (has the trailing Z).

Use it

CLI · DuckDB
$ finetype infer -i "2013-06-04T01:02:03.123" --mode column
→ datetime.timestamp.iso_milliseconds

SELECT ft_infer('2013-06-04T01:02:03.123');
-- → 'datetime.timestamp.iso_milliseconds'
Cast expression
strptime({col}, '%Y-%m-%dT%H:%M:%S.%g')
-- Format: %Y-%m-%dT%H:%M:%S.%g

Schema

https://meridian.online/schemas/datetime.timestamp.iso_milliseconds · Frictionless type datetime · any

finetype taxonomy datetime.timestamp.iso_milliseconds -o json-schema

Type Registry