{
  "id": 10990874,
  "title": "Why Your Date Shows 1970: Unix Timestamps in Seconds vs Milliseconds",
  "url": "https://urgent.news/2026/09/30/why-your-date-shows-1970-unix-timestamps-in-seconds-vs-milliseconds",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-30T17:01:12.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/calculatorspan/why-your-date-shows-1970-unix-timestamps-in-seconds-vs-milliseconds-243i"
  },
  "original_language": "en",
  "account": "Unix timestamps count the number of seconds or milliseconds since January 1, 1970. Different programming languages and systems use either seconds or milliseconds to represent these timestamps. When a program receives a timestamp from an API in one unit but expects it in another, it can lead to incorrect date outputs.\n\nOne common mistake is treating seconds as milliseconds, which results in a date showing January 20, 1970, instead of the correct date. To fix this, the number of seconds should be multiplied by 1000 to convert it to milliseconds before passing it to the `Date()` function.\n\nAnother mistake is treating milliseconds as seconds, which leads to a date showing the year 55,840. To address this, the number of milliseconds should be divided by 1000 to convert it to seconds before using it in the `Date()` function.\n\nTo avoid these issues, it's recommended to use the appropriate unit of measurement for timestamps in your code. For example, use `Date.now()` in JavaScript to get milliseconds, or `time.time()` in Python to get seconds. When receiving timestamps from an API, check the unit used by the API and convert it to the correct unit before using it in your code.\n\nNaming the unit in database fields or API responses can help prevent this bug. For instance, use `createdAtMs` for milliseconds or `createdAtSec` for seconds. In API specifications, document the unit used for timestamps, and prefer using one unit consistently across the entire API.\n\nWhen dealing with 32-bit signed integers for timestamps, be aware that they can overflow on January 19, 2038, at 03:14:07 UTC. To avoid this issue, use 64-bit integers for timestamps in new code.\n\nA handy way to check if a timestamp is in seconds or milliseconds is to count the number of digits. If the timestamp has 10 digits, it's likely in seconds. If it has 13 digits, it's likely in milliseconds. However, this method may not work for timestamps before March 1973, so it's better to know the unit from the API documentation and convert it explicitly in production code.\n\nBy following these guidelines and being mindful of the unit used for timestamps, you can avoid common mistakes and ensure accurate date outputs in your applications.",
  "summary": "Why Your Date Shows 1970: Unix Timestamps in Seconds vs Milliseconds You fetch a timestamp from an API, pass it to new Date(), and the screen says January 20, 1970. Or you get the opposite: a date in the year 55,840. Nothing is wrong with your date library. You've met the most common timestamp bug there is: mixing up seconds and milliseconds. What a Unix timestamp is Need to decode a timestamp…",
  "key_points": [
    "Unix timestamps count seconds or milliseconds since Jan 1, 1970",
    "Mistakes from treating seconds as milliseconds or vice versa",
    "Use appropriate unit in code to avoid incorrect dates"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}