Why Date Formats Are a Mess
- 01/02/03: Is this Jan 2, 2003? Feb 1, 2003? Feb 3, 2001? Depends on country!
- ISO 8601: Created 1988 to end the chaos: YYYY-MM-DD is unambiguous worldwide
- Unix epoch: Jan 1, 1970 was chosen arbitrarily—it was 'recent enough' in 1971
Date Format Standards Explained
- ISO 8601: 2024-01-15T14:30:00Z — International standard. The 'T' separates date/time, 'Z' = UTC
- Unix timestamp: Seconds since 1970-01-01 00:00:00 UTC. Simple integer, no timezone confusion
- RFC 2822: Mon, 15 Jan 2024 14:30:00 +0000 — Email format (Date: header)
- RFC 3339: Like ISO 8601 but stricter—required for internet protocols
The MM/DD vs DD/MM War
- MM/DD/YYYY: USA, Philippines, Palau, Micronesia, Canada (sometimes)
- DD/MM/YYYY: Most of the world: Europe, South America, Africa, Asia, Australia
- YYYY-MM-DD: ISO standard, China, Japan, Korea, Sweden, Hungary, Lithuania
- Pro tip: Always use ISO 8601 (YYYY-MM-DD) in code—it's unambiguous AND sorts correctly!
Unix Timestamp Facts
- Negative timestamps work: -1 = Dec 31, 1969 23:59:59 UTC
- JavaScript uses milliseconds (13 digits), Unix uses seconds (10 digits)
- Y2K38 bug: 32-bit timestamps overflow on Jan 19, 2038 03:14:07 UTC
- Fun: timestamp 1234567890 was Feb 13, 2009 23:31:30—developers celebrated!
- MongoDB ObjectId: First 4 bytes are Unix timestamp (8 hex chars)
Common Date Bugs
- JS months are 0-indexed: new Date(2024, 0, 15) = January 15 (not month 0!)
- Timezone confusion: 'new Date("2024-01-15")' parses as UTC, but '2024/01/15' parses as local
- Daylight Saving: March 10, 2024 2:30 AM didn't exist in US (clocks skipped to 3:00)
- Leap seconds: 2016-12-31 had 23:59:60—most systems just ignore this
- Year 2000: COBOL programmers used 2-digit years, causing the Y2K panic
Database Date Formats
- SQL DATETIME: '2024-01-15 14:30:00' — No timezone info (dangerous!)
- SQL TIMESTAMP: Usually stored as UTC, converted on retrieval
- PostgreSQL: TIMESTAMPTZ stores timezone offset (recommended)
- MongoDB: ISODate() wrapper around JavaScript Date objects
- Best practice: Store UTC always, convert to local only for display
Interesting Calendar Facts
- October 1582 lost 10 days: Oct 4 was followed by Oct 15 (Gregorian calendar adoption)
- Russia didn't switch until 1918—their 'October Revolution' was actually in November
- Excel thinks 1900 was a leap year (it wasn't)—intentional Lotus 1-2-3 compatibility bug
- GPS time doesn't have leap seconds—it's now 18 seconds ahead of UTC
- Japan uses year 1 = 660 BC (mythical Emperor Jimmu) for some purposes
Developer Use Cases
- Debug API timestamps: Paste Unix → see human-readable instantly
- Generate SQL seeds: Convert readable dates to database format
- Parse log files: Identify which timestamp format a system uses
- Compare timezones: Same instant, different representations
- JWT debugging: 'exp' and 'iat' claims are Unix timestamps