Converting standard dates to Unix timestamps in Excel can be a frustrating hurdle for analysts managing modern system integrations. While standard funding sources and legacy financial databases typically export records in traditional formats, web APIs require epoch time. Mastering this conversion grants analysts immediate compatibility across diverse database platforms. One key stipulation to keep in mind is adjusting your formula for local time zone offsets relative to UTC. Industry leaders like Shopify rely on this precise calculation to sync global transactional data. Below, we outline the exact Excel formulas and step-by-step configurations needed to streamline your workflow.
In the worlds of web development, database administration, and system logging, time is frequently recorded as a Unix timestamp (also known as Epoch time or POSIX time). A Unix timestamp is a single, continuous integer representing the total number of seconds that have elapsed since Thursday, January 1, 1970, at 00:00:00 Coordinated Universal Time (UTC).
While computers love Unix timestamps because they avoid timezone complexities and leap-year math, humans find them completely illegible. If you are importing external data from an API, a SQL database, or server logs into Microsoft Excel, you will likely need to convert these long strings of digits into readable, standard dates-or vice-versa. Fortunately, Excel can seamlessly bridge this gap using simple mathematical formulas. Here is a comprehensive guide on how to convert standard dates to Unix timestamps and convert Unix timestamps back to standard dates in Excel.
To convert dates in Excel, we must understand how both systems calculate time:
Because Excel measures time in days and Unix measures time in seconds, we must use a conversion factor. There are exactly 86,400 seconds in a day (24 hours × 60 minutes × 60 seconds).
Additionally, we need to account for the difference between the two start dates. In Excel's date serial system, January 1, 1970, corresponds to the serial value 25,569. This means exactly 25,569 days passed between Excel's start date (1900) and Unix's start date (1970).
If you have a human-readable date in Excel (e.g., 2023-11-15 14:30:00) and need to output its corresponding Unix timestamp, you will use a subtraction and multiplication formula.
=(A2 - DATE(1970,1,1)) * 86400
Or, using the static Excel serial number for January 1, 1970 (which is 25,569):
=(A2 - 25569) * 86400
A2 - 25569: This subtracts the Unix epoch start date from your target date, returning the difference in fractional days.* 86400: This multiplies the resulting number of days by the number of seconds in a day to output the total elapsed seconds.Unix timestamps are strictly UTC. If your local standard date in cell A2 is in Eastern Standard Time (EST, which is UTC-5), your Unix timestamp will be off by 5 hours unless you adjust for your offset. To convert a local date to a UTC Unix timestamp, you must subtract your timezone offset (in hours) before multiplying:
=((A2 - (TimezoneOffset / 24)) - 25569) * 86400
For EST (GMT-5), you would subtract 5 hours (written as -5/24 in Excel, which mathematically adds 5 hours to align with UTC):
=((A2 - (-5/24)) - 25569) * 86400
When you import raw Unix timestamps (e.g., 1700058600) into Excel, they will display as large numbers. To transform them back into readable dates, you reverse the math: divide by 86,400 and add the 1970 Epoch offset.
=(A2 / 86400) + DATE(1970,1,1)
Or, using the static serial value:
=(A2 / 86400) + 25569
When you first apply this formula, Excel may display a strange-looking decimal number (e.g., 45245.604). Do not panic! This is Excel's internal date serial format. To make it human-readable, you must format the cell:
yyyy-mm-dd hh:mm:ss or m/d/yyyy h:mm AM/PM.Many modern APIs and databases (like JavaScript applications and MongoDB) measure Unix time in milliseconds instead of seconds. These timestamps are easily recognizable because they contain 13 digits (e.g., 1700058600000) rather than the standard 10 digits.
If you try to convert a millisecond timestamp using the standard division factor of 86,400, your resulting date will point to the far future (often the year 40,000+!). To resolve this, you must increase your divisor by a factor of 1,000.
=(A2 / 86400000) + 25569
=(A2 - 25569) * 86400000
To help you implement these formulas quickly, refer to this summary table based on your data structure:
| Conversion Goal | Target Formula (Assuming Cell A2) | Output Format Setting |
|---|---|---|
| Standard Date → Unix (10-digit) | =(A2 - 25569) * 86400 |
General / Number (no decimals) |
| Standard Date → Unix Milliseconds (13-digit) | =(A2 - 25569) * 86400000 |
General / Number (no decimals) |
| Unix (10-digit) → Standard Date | =(A2 / 86400) + 25569 |
Custom: yyyy-mm-dd hh:mm:ss |
| Unix Milliseconds → Standard Date | =(A2 / 86400000) + 25569 |
Custom: yyyy-mm-dd hh:mm:ss.000 |
If you are using Microsoft 365 or Excel 2021, you can create your own custom, reusable functions using the LAMBDA feature. This allows you to avoid remembering the math and serial numbers every time you build a new sheet.
TO_UNIX=LAMBDA(date_val, (date_val - 25569) * 86400)FROM_UNIX=LAMBDA(unix_val, (unix_val / 86400) + 25569)Once saved, you can use these custom functions just like native Excel features. For example, typing =FROM_UNIX(A2) will immediately convert a Unix timestamp to an Excel date value.
Converting between standard dates and Unix timestamps in Microsoft Excel is straightforward once you understand how both systems represent time. By utilizing the magic conversion values-86,400 (seconds in a day) and 25,569 (the Excel date serial value for the 1970 Unix epoch)-you can easily write formulas to clean and standardize your datasets. Just remember to format your destination cells correctly, and watch your raw database logs transform into highly readable business reports.
Disclaimer:
The documents and templates provided on this page are for informational and illustrative purposes only. They do not constitute professional, legal, or financial advice, and should not be relied upon as such. Because individual circumstances and regulatory requirements vary, these materials may not be suitable for your specific needs. We recommend consulting with a qualified professional before adapting or using any of these examples for official or commercial purposes.