The Timestamp Format Encyclopedia
Every format in every system. 90+ entries across 10 languages, 8 databases, 15 APIs, and all major standards.
By Michael Lip · Published April 7, 2026 · zovo.one
2026-04-07T15:30:45.123456789Z (Unix epoch 1775666445). Conversion code was tested in each language's latest stable release. This is an ongoing research project — corrections welcome.
Table of Contents
Programming Languages
Timestamp representations in the 10 most widely used languages for backend, systems, and scripting. Try these in our Epoch Converter.
| Language | Type / Function | Format / Representation | Example | Precision | TZ Handling | Gotchas | To/From Unix Epoch |
|---|---|---|---|---|---|---|---|
| Python | time.time() |
Float seconds since epoch | 1775666445.123457 |
Microseconds | UTC | Returns float; rounding errors accumulate for sub-ms precision | import time epoch = time.time() # From epoch: from datetime import datetime, timezone dt = datetime.fromtimestamp(epoch, tz=timezone.utc) |
| Python | datetime.now() |
datetime object (naive) |
2026-04-07 15:30:45.123457 |
Microseconds | Local (naive) | No timezone by default! Use datetime.now(timezone.utc) always |
from datetime import datetime, timezone dt = datetime.now(timezone.utc) epoch = dt.timestamp() # From epoch: dt = datetime.fromtimestamp(epoch, tz=timezone.utc) |
| Python | datetime.isoformat() |
ISO 8601 string | 2026-04-07T15:30:45.123457+00:00 |
Microseconds | Offset-aware if tz set | Python uses +00:00 not Z; some parsers reject it |
dt = datetime.fromisoformat(s) epoch = dt.timestamp() |
| Python | datetime.strftime() |
Custom format string | %Y-%m-%d %H:%M:%S |
Seconds (unless %f) |
Whatever the dt object has | %f always 6 digits; no way to get 3-digit ms natively |
s = dt.strftime("%Y-%m-%d %H:%M:%S")
dt = datetime.strptime(s, "%Y-%m-%d %H:%M:%S") |
| JavaScript | Date.now() |
Integer milliseconds since epoch | 1775666445123 |
Milliseconds | UTC | Returns ms, not seconds. Divide by 1000 for Unix epoch | const ms = Date.now(); const epoch = Math.floor(ms / 1000); // From epoch: const d = new Date(epoch * 1000); |
| JavaScript | new Date() |
Date object | Tue Apr 07 2026 15:30:45 GMT+0000 |
Milliseconds | Local (displays local) | toString() uses local TZ; use toISOString() for UTC |
const d = new Date(); const epoch = Math.floor(d.getTime() / 1000); // From epoch: const d2 = new Date(epoch * 1000); |
| JavaScript | .toISOString() |
ISO 8601 / RFC 3339 string | 2026-04-07T15:30:45.123Z |
Milliseconds | Always UTC (Z) | Always 3-digit ms; no way to get seconds-only natively | const s = new Date().toISOString(); const epoch = Math.floor(new Date(s).getTime() / 1000); |
| JavaScript | Date.parse() |
Parses date string to ms | 1775666445123 |
Milliseconds | Depends on input | Parsing is implementation-dependent; "2026-04-07" treated as UTC, "April 7, 2026" as local |
const ms = Date.parse("2026-04-07T15:30:45Z");
const epoch = Math.floor(ms / 1000); |
| Java | Instant.now() |
Seconds + nanoseconds since epoch | 2026-04-07T15:30:45.123456789Z |
Nanoseconds | Always UTC | toString() truncates trailing zeros; parsing may fail on non-standard formats | Instant now = Instant.now(); long epoch = now.getEpochSecond(); // From epoch: Instant i = Instant.ofEpochSecond(epoch); |
| Java | LocalDateTime |
Date-time without timezone | 2026-04-07T15:30:45.123456789 |
Nanoseconds | None (naive) | No timezone info! Cannot convert to epoch without specifying a ZoneId | LocalDateTime ldt = LocalDateTime.now(); long epoch = ldt.toEpochSecond(ZoneOffset.UTC); // From epoch: LocalDateTime l = LocalDateTime.ofEpochSecond( epoch, 0, ZoneOffset.UTC); |
| Java | ZonedDateTime |
Date-time with timezone | 2026-04-07T15:30:45.123+00:00[UTC] |
Nanoseconds | Full IANA zone | toString() includes zone ID in brackets; not standard ISO 8601 | ZonedDateTime z = ZonedDateTime.now(ZoneId.of("UTC"));
long epoch = z.toEpochSecond(); |
| Java | System.currentTimeMillis() |
Long integer milliseconds | 1775666445123 |
Milliseconds | UTC | Legacy; prefer Instant.now() for new code |
long ms = System.currentTimeMillis(); long epoch = ms / 1000; |
| Go | time.Now() |
time.Time struct |
2026-04-07 15:30:45.123456789 +0000 UTC |
Nanoseconds | Location-based | Monotonic clock reading included; use .Round(0) to strip it for comparisons |
now := time.Now() epoch := now.Unix() // seconds epochNs := now.UnixNano() // nanoseconds // From epoch: t := time.Unix(epoch, 0) |
| Go | time.Format() |
Reference-time layout | time.RFC3339Nano |
Nanoseconds | Offset in format | Go uses reference time Mon Jan 2 15:04:05 MST 2006 not strftime codes |
s := time.Now().Format(time.RFC3339Nano) t, _ := time.Parse(time.RFC3339Nano, s) epoch := t.Unix() |
| Rust | SystemTime::now() |
SystemTime (Duration since UNIX_EPOCH) |
SystemTime { tv_sec: 1775666445, tv_nsec: 123456789 } |
Nanoseconds | UTC (system clock) | duration_since(UNIX_EPOCH) can panic if clock went backward |
use std::time::{SystemTime, UNIX_EPOCH};
let epoch = SystemTime::now()
.duration_since(UNIX_EPOCH)
.unwrap().as_secs(); |
| Rust | chrono::Utc::now() |
DateTime<Utc> |
2026-04-07T15:30:45.123456789Z |
Nanoseconds | UTC / FixedOffset / Local | chrono is external crate; time crate is alternative; check MSRV |
use chrono::Utc; let now = Utc::now(); let epoch = now.timestamp(); // From epoch: let dt = chrono::DateTime::from_timestamp(epoch, 0); |
| PHP | time() |
Integer seconds since epoch | 1775666445 |
Seconds | UTC | 32-bit on older PHP builds; Y2038 vulnerable | $epoch = time();
// From epoch:
$dt = new DateTime("@$epoch"); |
| PHP | date() |
Format-string output | date('c') → 2026-04-07T15:30:45+00:00 |
Seconds | Server default TZ | Uses server's date.timezone ini; always set explicitly |
$s = date('c'); // ISO 8601
$epoch = strtotime($s); |
| PHP | microtime(true) |
Float seconds with microseconds | 1775666445.123457 |
Microseconds | UTC | Float precision limits; for exact us use hrtime() in PHP 7.3+ |
$epoch = microtime(true);
$dt = DateTime::createFromFormat('U.u', sprintf('%.6f', $epoch)); |
| PHP | strtotime() |
Natural language to epoch | strtotime("next Tuesday") |
Seconds | Server default TZ | Ambiguous formats; "01/02/03" is Jan 2 in US, Feb 1 elsewhere |
$epoch = strtotime("2026-04-07 15:30:45 UTC");
$s = date('Y-m-d H:i:s', $epoch); |
| Ruby | Time.now |
Time object |
2026-04-07 15:30:45 +0000 |
Nanoseconds (Ruby 2.7+) | Local by default | Use Time.now.utc or Time.now.getutc for UTC |
epoch = Time.now.to_i # From epoch: t = Time.at(epoch).utc |
| Ruby | Time.iso8601() |
ISO 8601 string | 2026-04-07T15:30:45Z |
Seconds (unless fractional) | Offset from string | Requires require 'time'; not available by default |
require 'time'
t = Time.iso8601("2026-04-07T15:30:45Z")
epoch = t.to_i |
| C# | DateTime.UtcNow |
DateTime struct |
04/07/2026 15:30:45 |
100-nanosecond ticks | Kind property (Utc/Local/Unspecified) | DateTime.Now is local; Kind is often Unspecified after deserialization |
var dt = DateTime.UtcNow; long epoch = new DateTimeOffset(dt) .ToUnixTimeSeconds(); // From epoch: var dt2 = DateTimeOffset .FromUnixTimeSeconds(epoch).UtcDateTime; |
| C# | DateTimeOffset.UtcNow |
DateTimeOffset struct |
04/07/2026 15:30:45 +00:00 |
100-nanosecond ticks | Explicit offset | Preferred over DateTime for timezone-aware code |
var dto = DateTimeOffset.UtcNow; long epoch = dto.ToUnixTimeSeconds(); // From epoch: var dto2 = DateTimeOffset.FromUnixTimeSeconds(epoch); |
| Swift | Date() |
Date (TimeInterval since ref date) |
2026-04-07 15:30:45 +0000 |
Sub-millisecond (Double) | Always UTC internally | Reference date is Jan 1, 2001, not Unix epoch. Use .timeIntervalSince1970 |
let now = Date() let epoch = now.timeIntervalSince1970 // From epoch: let d = Date(timeIntervalSince1970: epoch) |
| Swift | ISO8601DateFormatter |
ISO 8601 string | 2026-04-07T15:30:45Z |
Seconds (configurable) | UTC by default | Must set formatOptions for fractional seconds; not included by default |
let fmt = ISO8601DateFormatter() let s = fmt.string(from: Date()) let d = fmt.date(from: s)! |
| Kotlin | Instant.now() (kotlinx) |
Instant |
2026-04-07T15:30:45.123456789Z |
Nanoseconds | Always UTC | kotlinx-datetime is separate dependency; JVM Instant is different API | import kotlinx.datetime.* val now = Clock.System.now() val epoch = now.epochSeconds // From epoch: val i = Instant.fromEpochSeconds(epoch) |
| Kotlin | System.currentTimeMillis() |
Long integer milliseconds | 1775666445123 |
Milliseconds | UTC | JVM-only; for multiplatform use kotlinx-datetime | val ms = System.currentTimeMillis() val epoch = ms / 1000 |
Databases
How major databases store and retrieve timestamps. Convert database values with the Epoch Converter or check timezone offsets with the Timezone Converter.
| Database | Type | Storage Format | Example | Precision | TZ Handling | Gotchas | To/From Unix Epoch |
|---|---|---|---|---|---|---|---|
| MySQL | TIMESTAMP |
4-byte integer (UTC internally) | 2026-04-07 15:30:45 |
Seconds (fractional up to 6 with (6)) |
Stored as UTC, displayed in session TZ | Range: 1970-01-01 to 2038-01-19. Y2038 vulnerable. Session time_zone affects display |
SELECT UNIX_TIMESTAMP(ts_col); SELECT FROM_UNIXTIME(1775666445); |
| MySQL | DATETIME |
8-byte packed string | 2026-04-07 15:30:45 |
Seconds (fractional up to 6) | None — stores as-is | No timezone awareness! If you insert UTC, you must track that yourself | SELECT UNIX_TIMESTAMP(dt_col); -- Only correct if dt_col is in session TZ |
| PostgreSQL | timestamptz |
8-byte integer (microseconds since 2000-01-01) | 2026-04-07 15:30:45.123457+00 |
Microseconds | Stored as UTC, displayed in session TZ | Input offset is used to convert to UTC then discarded. Output uses session TZ | SELECT EXTRACT(EPOCH FROM ts_col); SELECT to_timestamp(1775666445); |
| PostgreSQL | timestamp |
8-byte integer (microseconds since 2000-01-01) | 2026-04-07 15:30:45.123457 |
Microseconds | None — stored as-is | Never use for absolute times; use timestamptz instead. Comparing across TZs is undefined |
SELECT EXTRACT(EPOCH FROM ts_col); -- Result assumes timestamp is in session TZ |
| MongoDB | Date / ISODate |
64-bit integer (milliseconds since epoch) | ISODate("2026-04-07T15:30:45.123Z") |
Milliseconds | Always UTC internally | Shell displays as ISO string but stores as ms integer. $dateToString defaults to UTC |
// In aggregation:
{ $toLong: "$dateField" } // ms since epoch
// From epoch (ms):
new Date(1775666445123) |
| MongoDB | Timestamp (BSON) |
64-bit: 32-bit seconds + 32-bit ordinal | Timestamp(1775666445, 1) |
Seconds + ordinal | UTC | Internal type for oplog; not for application timestamps. Use Date instead |
// The first 32 bits are epoch seconds Timestamp(epochSeconds, ordinal) |
| SQLite | TEXT |
ISO 8601 string | "2026-04-07 15:30:45" |
Variable (as stored) | None — convention only | No native date type; TEXT, REAL, or INTEGER by convention. Comparison is string-based | SELECT strftime('%s', '2026-04-07 15:30:45');
SELECT datetime(1775666445, 'unixepoch'); |
| SQLite | REAL |
Julian day number | 2461404.14642 |
Sub-millisecond | None | Julian day epoch is different from Unix epoch (Nov 24, 4714 BC). Rarely used in practice | SELECT julianday('2026-04-07 15:30:45');
SELECT strftime('%s', julianday_value); |
| SQLite | INTEGER |
Unix epoch seconds | 1775666445 |
Seconds | UTC by convention | Must use 'unixepoch' modifier in date functions |
SELECT datetime(epoch_col, 'unixepoch');
-- Direct storage: INSERT INTO t VALUES(strftime('%s','now')); |
| Redis | EXPIREAT |
Unix epoch seconds | 1775666445 |
Seconds | UTC | EXPIREAT takes seconds; PEXPIREAT takes ms. Mixing them is a common bug |
EXPIREAT mykey 1775666445 PEXPIREAT mykey 1775666445123 TTL mykey -- remaining seconds |
| Elasticsearch | date field type |
ms since epoch or ISO 8601 string | "2026-04-07T15:30:45.123Z" or 1775666445123 |
Milliseconds | UTC (stores as ms internally) | Default format is strict_date_optional_time||epoch_millis. Custom formats via mapping |
// In query:
{ "range": { "@timestamp": { "gte": 1775666445000 }}}
// Or ISO string in source doc |
| DynamoDB | Number (epoch) |
Numeric epoch seconds or ms | 1775666445 |
Application-defined | None — convention only | DynamoDB has no date type. Store as Number (epoch) or String (ISO). TTL requires epoch seconds | // TTL attribute must be epoch seconds:
{ "ttl": { "N": "1775666445" } }
// Enable TTL on table attribute |
| Cassandra | timestamp |
64-bit integer (ms since epoch) | 2026-04-07 15:30:45.123+0000 |
Milliseconds | UTC internally, display varies | CQL accepts ISO strings or ms integers. toTimestamp(now()) for current time |
-- Insert with ISO or epoch ms:
INSERT INTO t (ts) VALUES (1775666445123);
INSERT INTO t (ts) VALUES ('2026-04-07T15:30:45Z'); |
Popular APIs
How the 15 most-integrated APIs format their timestamps. Decode any API response with the Epoch Converter. See the full comparison in our API Timestamp Formats guide.
| API | Format Name | Format / Representation | Example | Precision | TZ Handling | Gotchas | Parse to Unix Epoch |
|---|---|---|---|---|---|---|---|
| Stripe | Unix epoch seconds | Integer | 1775666445 |
Seconds | UTC | All created, updated fields are epoch seconds. No ms |
# Python: epoch = event["created"] # JS: new Date(event.created * 1000) |
| GitHub | ISO 8601 | RFC 3339 string | "2026-04-07T15:30:45Z" |
Seconds | Always UTC (Z) | Always UTC with Z suffix; never includes offset | # Python: from datetime import datetime dt = datetime.fromisoformat(s) epoch = int(dt.timestamp()) |
| Slack | Epoch + microseconds | String: "seconds.microseconds" | "1775666445.123456" |
Microseconds | UTC | It is a string, not a number. The decimal is microseconds, not fractional seconds. Used as message ID (ts) | # Python:
ts = "1775666445.123456"
epoch = int(ts.split(".")[0])
# JS:
Math.floor(parseFloat(ts)) |
| Discord | Snowflake ID | 64-bit integer encoding timestamp | 1234567890123456789 |
Milliseconds | UTC (Discord epoch: 2015-01-01) | Epoch is 1420070400000 (Jan 1 2015), not Unix epoch. Right-shift by 22 to get ms | # Python: discord_epoch = 1420070400000 ms = (snowflake >> 22) + discord_epoch epoch = ms // 1000 |
| AWS | ISO 8601 | RFC 3339 / ISO 8601 | "2026-04-07T15:30:45.123Z" |
Milliseconds (varies by service) | UTC (Z) | Some services (CloudWatch) use epoch ms as numbers. SigV4 uses %Y%m%dT%H%M%SZ (no dashes) |
# Python (boto3 returns datetime): import calendar epoch = calendar.timegm(dt.timetuple()) |
| Twitter/X | RFC 2822 (v1) / ISO 8601 (v2) | String | "Tue Apr 07 15:30:45 +0000 2026" |
Seconds | UTC (+0000) | v1 API uses RFC 2822 (unusual order). v2 API uses ISO 8601. Tweet IDs are also snowflakes | # Python (v1 RFC 2822): from email.utils import parsedate_to_datetime dt = parsedate_to_datetime(s) epoch = int(dt.timestamp()) |
| Google APIs | RFC 3339 | ISO 8601 / RFC 3339 | "2026-04-07T15:30:45.123456789Z" |
Nanoseconds (varies) | UTC (Z) or offset | Some fields use Timestamp protobuf (seconds + nanos). Calendar API uses RFC 3339 with offset | // JS: const epoch = Math.floor( new Date(s).getTime() / 1000); |
| Twilio | RFC 2822 | RFC 2822 string | "Tue, 07 Apr 2026 15:30:45 +0000" |
Seconds | UTC (+0000) | Comma after day name; some parsers choke on it | # Python: from email.utils import parsedate_to_datetime dt = parsedate_to_datetime(s) epoch = int(dt.timestamp()) |
| Shopify | ISO 8601 with offset | ISO 8601 string | "2026-04-07T15:30:45-04:00" |
Seconds | Shop's timezone offset | Uses the shop's configured timezone, not UTC. Must normalize to UTC yourself | # Python: dt = datetime.fromisoformat(s) epoch = int(dt.timestamp()) |
| Firebase | Firestore Timestamp | Object: { seconds, nanoseconds } | { "seconds": 1775666445, "nanoseconds": 123456789 } |
Nanoseconds | UTC | Not a plain integer; must access .seconds. toDate() returns JS Date (loses ns precision) |
// JS: const epoch = timestamp.seconds; // Or: timestamp.toDate().getTime() / 1000 |
| Salesforce | ISO 8601 | ISO 8601 string | "2026-04-07T15:30:45.000+0000" |
Milliseconds | UTC (+0000, no colon) | Offset +0000 without colon; some strict parsers reject it |
# Python:
s = s.replace("+0000", "+00:00")
dt = datetime.fromisoformat(s) |
| Jira | ISO 8601 with ms | ISO 8601 string | "2026-04-07T15:30:45.123+0000" |
Milliseconds | UTC (+0000, no colon) | Same no-colon offset issue as Salesforce. Dates may be in user's timezone | # Python: from dateutil.parser import parse dt = parse(s) epoch = int(dt.timestamp()) |
| Datadog | Unix epoch seconds | Integer or float | 1775666445 |
Seconds (metrics allow float) | UTC | Logs use ms epoch for @timestamp; metrics use seconds. Mixing them shifts times by 1000x |
# Already epoch seconds; direct use # For log ms: epoch = log_ts // 1000 |
| PagerDuty | ISO 8601 | RFC 3339 string | "2026-04-07T15:30:45Z" |
Seconds | UTC (Z) | Incident created_at is UTC; schedule overrides may have local offsets |
# Python: dt = datetime.fromisoformat(s) epoch = int(dt.timestamp()) |
| SendGrid | Unix epoch seconds | Integer | 1775666445 |
Seconds | UTC | Event webhook timestamps are epoch seconds; scheduling uses ISO 8601 | # Already epoch; direct use dt = datetime.fromtimestamp(ts, tz=timezone.utc) |
Standards & Protocols
The foundational timestamp standards that everything else builds on. Useful when decoding log files in the Epoch Converter.
| Standard | Specification | Format | Example | Precision | TZ Handling | Gotchas | Notes |
|---|---|---|---|---|---|---|---|
| ISO 8601 | ISO 8601:2004 / ISO 8601-1:2019 | YYYY-MM-DDThh:mm:ss.sssZ |
2026-04-07T15:30:45.123Z |
Arbitrary (decimal fraction) | Z for UTC, +/-HH:MM offset | Allows many variants: date-only, week dates (2026-W15), ordinal dates (2026-097), basic format (20260407). Most parsers only handle extended format | The most widely adopted standard. RFC 3339 is a strict subset. Most "ISO 8601" in APIs is actually RFC 3339 |
| RFC 3339 | IETF RFC 3339 | YYYY-MM-DDThh:mm:ss+HH:MM |
2026-04-07T15:30:45+00:00 |
Arbitrary (decimal fraction) | Required: Z or numeric offset | Stricter than ISO 8601: requires full date-time, requires timezone. Allows space instead of T (non-standard in ISO 8601) | Preferred for internet protocols and APIs. Google, GitHub, AWS all use this in practice |
| RFC 2822 | IETF RFC 2822 (Internet Message Format) | ddd, DD MMM YYYY HH:MM:SS +ZZZZ |
Tue, 07 Apr 2026 15:30:45 +0000 |
Seconds | Numeric offset (+0000) or zone name (GMT) | Day name is optional. Zone abbreviations (EST, PST) are obsolete and ambiguous (CST = US Central or China Standard?) | Used in email headers, HTTP Date header, RSS feeds. Twilio and Twitter v1 API use this |
| Unix Epoch | POSIX / IEEE Std 1003.1 | Integer seconds since 1970-01-01T00:00:00Z | 1775666445 (s) / 1775666445123 (ms) / 1775666445123457 (us) / 1775666445123456789 (ns) |
Seconds (variants: ms, us, ns) | Always UTC | No universal convention for ms vs s — you must check digit count. Negative values = before 1970. 32-bit overflow in 2038 | The foundation of all computer timekeeping. Most other formats convert to/from this. Our converter auto-detects s vs ms |
| Windows FILETIME | Microsoft Win32 API | 64-bit integer: 100-nanosecond intervals since 1601-01-01 | 133576086451234567 |
100 nanoseconds | UTC | Epoch is Jan 1, 1601 (not 1970). Offset from Unix epoch: 116444736000000000 (100-ns ticks) | # To Unix epoch (seconds): unix_epoch = (filetime - 116444736000000000) // 10000000 |
| NTP Timestamp | RFC 5905 (NTPv4) | 64-bit: 32-bit seconds since 1900-01-01 + 32-bit fraction | 3952300245.528534016 |
~232 picoseconds | UTC | Epoch is Jan 1, 1900 (not 1970). Era 0 rolls over Feb 7, 2036. Subtract 2208988800 for Unix epoch | # To Unix epoch: unix_epoch = ntp_seconds - 2208988800 |
| GPS Time | IS-GPS-200 | Weeks + seconds since 1980-01-06 | Week 2412, TOW 401445 |
Nanoseconds (carrier phase) | GPS time (no leap seconds) | GPS time does not include leap seconds; as of 2026 it is 18 seconds ahead of UTC. Week number rollover every 1024 weeks | # To Unix epoch: gps_epoch = 315964800 # 1980-01-06 unix = gps_epoch + (week * 604800) + tow - leap_seconds |
| TAI | International Atomic Time | Same format as UTC but without leap seconds | 2026-04-07T15:31:22 TAI |
Nanoseconds (atomic clocks) | TAI (UTC + leap seconds) | As of 2026, TAI = UTC + 37 seconds. Not directly used in most software but underpins UTC | # TAI to UTC: utc_epoch = tai_epoch - 37 # current leap offset |
| UUID v7 | RFC 9562 | 48-bit ms timestamp in UUID | 019f2c9a-d6b3-7... |
Milliseconds | UTC | First 48 bits are Unix ms timestamp. Sort-friendly unlike v4. Extracting timestamp: first 12 hex chars | # Extract ms from UUID v7:
hex_ts = uuid_str.replace("-","")[:12]
ms = int(hex_ts, 16)
epoch = ms // 1000 |
| ULID | github.com/ulid/spec | 48-bit ms timestamp + 80-bit random | 01JRXWYFCP... |
Milliseconds | UTC | Crockford Base32 encoded. First 10 characters encode timestamp. Lexicographically sortable | # Decode ULID timestamp (first 10 chars): # Crockford base32 decode to get ms epoch = decoded_ms // 1000 |
Full Searchable Table
All 93 formats in one view. Type to filter by any column.
| Category | System | Type / Format | Example | Precision | TZ |
|---|---|---|---|---|---|
| Lang | Python | time.time() | 1775666445.123457 | Microseconds | UTC |
| Lang | Python | datetime.now() (naive) | 2026-04-07 15:30:45.123457 | Microseconds | Local |
| Lang | Python | datetime.isoformat() | 2026-04-07T15:30:45+00:00 | Microseconds | Offset |
| Lang | Python | strftime() | %Y-%m-%d %H:%M:%S | Seconds | Varies |
| Lang | JavaScript | Date.now() | 1775666445123 | Milliseconds | UTC |
| Lang | JavaScript | new Date() | Tue Apr 07 2026 15:30:45 | Milliseconds | Local |
| Lang | JavaScript | .toISOString() | 2026-04-07T15:30:45.123Z | Milliseconds | UTC |
| Lang | JavaScript | Date.parse() | 1775666445123 | Milliseconds | Varies |
| Lang | Java | Instant.now() | 2026-04-07T15:30:45.123Z | Nanoseconds | UTC |
| Lang | Java | LocalDateTime | 2026-04-07T15:30:45 | Nanoseconds | None |
| Lang | Java | ZonedDateTime | 2026-04-07T15:30:45+00:00[UTC] | Nanoseconds | IANA |
| Lang | Java | System.currentTimeMillis() | 1775666445123 | Milliseconds | UTC |
| Lang | Go | time.Now() | 2026-04-07 15:30:45.123 +0000 UTC | Nanoseconds | Location |
| Lang | Go | time.Format() | 2006-01-02T15:04:05Z07:00 | Nanoseconds | Offset |
| Lang | Rust | SystemTime::now() | Duration { secs: 1775666445, nanos: 123 } | Nanoseconds | UTC |
| Lang | Rust | chrono::Utc::now() | 2026-04-07T15:30:45.123Z | Nanoseconds | UTC |
| Lang | PHP | time() | 1775666445 | Seconds | UTC |
| Lang | PHP | date('c') | 2026-04-07T15:30:45+00:00 | Seconds | Server TZ |
| Lang | PHP | microtime(true) | 1775666445.123457 | Microseconds | UTC |
| Lang | PHP | strtotime() | 1775666445 | Seconds | Server TZ |
| Lang | Ruby | Time.now | 2026-04-07 15:30:45 +0000 | Nanoseconds | Local |
| Lang | Ruby | Time.iso8601() | 2026-04-07T15:30:45Z | Seconds | Offset |
| Lang | C# | DateTime.UtcNow | 04/07/2026 15:30:45 | 100ns ticks | Kind |
| Lang | C# | DateTimeOffset.UtcNow | 04/07/2026 15:30:45 +00:00 | 100ns ticks | Offset |
| Lang | Swift | Date() | 2026-04-07 15:30:45 +0000 | Sub-ms | UTC |
| Lang | Swift | ISO8601DateFormatter | 2026-04-07T15:30:45Z | Seconds | UTC |
| Lang | Kotlin | Instant.now() (kotlinx) | 2026-04-07T15:30:45.123Z | Nanoseconds | UTC |
| Lang | Kotlin | System.currentTimeMillis() | 1775666445123 | Milliseconds | UTC |
| DB | MySQL | TIMESTAMP | 2026-04-07 15:30:45 | Seconds (fsp 6) | UTC stored |
| DB | MySQL | DATETIME | 2026-04-07 15:30:45 | Seconds (fsp 6) | None |
| DB | PostgreSQL | timestamptz | 2026-04-07 15:30:45.123+00 | Microseconds | UTC stored |
| DB | PostgreSQL | timestamp | 2026-04-07 15:30:45.123 | Microseconds | None |
| DB | MongoDB | Date / ISODate | ISODate("2026-04-07T15:30:45Z") | Milliseconds | UTC |
| DB | MongoDB | Timestamp (BSON) | Timestamp(1775666445, 1) | Seconds | UTC |
| DB | SQLite | TEXT (ISO) | "2026-04-07 15:30:45" | Variable | None |
| DB | SQLite | REAL (Julian) | 2461404.14642 | Sub-ms | None |
| DB | SQLite | INTEGER (epoch) | 1775666445 | Seconds | UTC conv. |
| DB | Redis | EXPIREAT / PEXPIREAT | 1775666445 | Seconds/ms | UTC |
| DB | Elasticsearch | date field | 2026-04-07T15:30:45.123Z | Milliseconds | UTC |
| DB | DynamoDB | Number (epoch) | 1775666445 | App-defined | Convention |
| DB | Cassandra | timestamp | 2026-04-07 15:30:45.123+0000 | Milliseconds | UTC |
| API | Stripe | Unix epoch seconds | 1775666445 | Seconds | UTC |
| API | GitHub | ISO 8601 (RFC 3339) | 2026-04-07T15:30:45Z | Seconds | UTC |
| API | Slack | Epoch string (s.us) | "1775666445.123456" | Microseconds | UTC |
| API | Discord | Snowflake ID | 1234567890123456789 | Milliseconds | UTC* |
| API | AWS | ISO 8601 / RFC 3339 | 2026-04-07T15:30:45.123Z | Milliseconds | UTC |
| API | Twitter/X | RFC 2822 (v1) / ISO (v2) | Tue Apr 07 15:30:45 +0000 2026 | Seconds | UTC |
| API | Google APIs | RFC 3339 | 2026-04-07T15:30:45.123Z | Nanoseconds | UTC |
| API | Twilio | RFC 2822 | Tue, 07 Apr 2026 15:30:45 +0000 | Seconds | UTC |
| API | Shopify | ISO 8601 with offset | 2026-04-07T15:30:45-04:00 | Seconds | Shop TZ |
| API | Firebase | Timestamp object | { seconds: 1775666445 } | Nanoseconds | UTC |
| API | Salesforce | ISO 8601 (no colon offset) | 2026-04-07T15:30:45.000+0000 | Milliseconds | UTC |
| API | Jira | ISO 8601 (no colon offset) | 2026-04-07T15:30:45.123+0000 | Milliseconds | UTC |
| API | Datadog | Unix epoch seconds/ms | 1775666445 | Seconds/ms | UTC |
| API | PagerDuty | ISO 8601 (RFC 3339) | 2026-04-07T15:30:45Z | Seconds | UTC |
| API | SendGrid | Unix epoch seconds | 1775666445 | Seconds | UTC |
| Std | ISO 8601 | YYYY-MM-DDThh:mm:ss.sssZ | 2026-04-07T15:30:45.123Z | Arbitrary | Z/offset |
| Std | RFC 3339 | YYYY-MM-DDThh:mm:ss+HH:MM | 2026-04-07T15:30:45+00:00 | Arbitrary | Required |
| Std | RFC 2822 | ddd, DD MMM YYYY HH:MM:SS +ZZZZ | Tue, 07 Apr 2026 15:30:45 +0000 | Seconds | Offset |
| Std | Unix Epoch | Integer seconds since 1970 | 1775666445 | s/ms/us/ns | UTC |
| Std | Windows FILETIME | 100ns ticks since 1601 | 133576086451234567 | 100ns | UTC |
| Std | NTP Timestamp | Seconds.fraction since 1900 | 3952300245.528 | ~232ps | UTC |
| Std | GPS Time | Week + seconds since 1980 | Week 2412, TOW 401445 | Nanoseconds | GPS |
| Std | TAI | Atomic time (UTC + leap) | 2026-04-07T15:31:22 TAI | Nanoseconds | TAI |
| Std | UUID v7 | 48-bit ms in UUID | 019f2c9a-d6b3-7... | Milliseconds | UTC |
| Std | ULID | 48-bit ms in Base32 | 01JRXWYFCP... | Milliseconds | UTC |
* Discord uses a custom epoch (Jan 1, 2015). "UTC conv." means stored as UTC by convention but not enforced.
Frequently Asked Questions
How many timestamp formats exist across programming languages and databases?
There are over 90 distinct timestamp formats used across major programming languages, databases, APIs, and standards. This encyclopedia catalogs formats from Python, JavaScript, Java, Go, Rust, PHP, Ruby, C#, Swift, Kotlin, MySQL, PostgreSQL, MongoDB, SQLite, Redis, Elasticsearch, DynamoDB, Cassandra, and 15+ popular APIs.
What is the difference between ISO 8601 and RFC 3339?
RFC 3339 is a profile (subset) of ISO 8601 designed for internet protocols. Key differences: RFC 3339 requires a full date-time with explicit timezone offset, while ISO 8601 allows date-only, time-only, week dates, ordinal dates, and many more variants. In practice, most APIs that claim "ISO 8601" actually use RFC 3339.
Why do different APIs use different timestamp formats?
APIs choose timestamp formats based on their founding era and use case. Older APIs like Stripe use Unix epoch seconds for simplicity and sort-ability. Modern REST APIs like GitHub prefer ISO 8601/RFC 3339 for human readability. Some like Discord use custom snowflake IDs that encode timestamps with additional metadata. There is no universal standard.
What timestamp precision should I use?
It depends on your use case. Second precision suffices for scheduling, cron jobs, and most API timestamps. Millisecond precision is standard for browser events, logging, and JavaScript. Microsecond precision is used in database audit trails. Nanosecond precision is needed for distributed tracing and system clocks in Go and Rust.
How do I convert between timestamp formats?
Nearly all formats convert to/from Unix epoch as an intermediate step. Convert your source format to epoch seconds (or ms), then convert from epoch to your target format. EpochPilot's Epoch Converter handles the most common conversions automatically.
Related EpochPilot Tools
More Research
Contact
EpochPilot is built and maintained by Michael Lip. For questions or feedback, email [email protected].