Blog
Wild & Free Tools

Convert Unix Timestamp in Power BI — DAX and Power Query

Last updated: April 2026 6 min read

Table of Contents

  1. Power Query Method
  2. DAX Method
  3. Timezone Handling
  4. Frequently Asked Questions

Power BI has two places where you can convert a Unix timestamp: Power Query (during data load) and DAX (after the data is in the model). Each one solves a different problem. Power Query is the right place if your raw data has timestamps you want stored as dates. DAX is the right place if you need a calculated column or measure that converts on the fly.

This guide covers both. If you just need a quick one-off conversion without firing up Power BI, the free Unix timestamp converter handles it in your browser.

Convert in Power Query (Recommended for Loaded Data)

Power Query (the M language) handles Unix timestamps cleanly with date arithmetic. The pattern: start with the epoch reference date, add the seconds as a duration, get back a datetime.

// In Power Query, add a custom column
= #datetime(1970, 1, 1, 0, 0, 0) + #duration(0, 0, 0, [UnixTimestamp])

// For milliseconds, divide by 1000 first
= #datetime(1970, 1, 1, 0, 0, 0) + #duration(0, 0, 0, [UnixMs] / 1000)

The result is a datetime in UTC. Power BI will display it in your model timezone, which by default is whatever the report's system uses. To force a specific zone, use DateTime.AddZone after the conversion.

Going from datetime back to Unix

// Datetime to Unix seconds
= Number.RoundDown(Duration.TotalSeconds([DateColumn] - #datetime(1970, 1, 1, 0, 0, 0)))

This is the right place to do timestamp conversion if you can — converting at load time means the rest of your model works with proper datetime columns and you get full date hierarchy support, time intelligence functions, and proper sorting.

Sell Custom Apparel — We Handle Printing & Free Shipping

Convert in DAX (For Calculated Columns and Measures)

If your model already has a Unix timestamp column and you want to convert it without going back to Power Query, DAX can handle it with the same date-arithmetic trick.

// Calculated column — Unix seconds to datetime
ConvertedDate = DATE(1970, 1, 1) + (Table[UnixTimestamp] / 86400)

// For milliseconds
ConvertedDate = DATE(1970, 1, 1) + (Table[UnixMs] / 86400000)

// Going back — datetime to Unix seconds
UnixSeconds = INT((Table[DateTime] - DATE(1970, 1, 1)) * 86400)

The 86400 number is the seconds in a day. DAX dates are stored as days since 1899-12-30 internally, so adding fractions of a day to a date gives you a datetime.

Why Power Query is usually better than DAX for this

DAX calculated columns are computed at refresh time and stored in the model — they take up memory and slow down refresh. Power Query happens at load time and the result is just a regular column. For a one-time conversion of incoming timestamps, do it in Power Query. Reserve DAX for cases where you need the conversion to depend on a measure or filter context.

Timezones in Power BI

Power BI date/time columns have no timezone metadata by default. They store wall-clock values without context. This causes the same problems as in any other tool: report viewers in different timezones can see different "current time" displays for the same data.

Force UTC interpretation

// Power Query — convert to a DateTimeZone explicitly
= DateTime.AddZone(
    #datetime(1970, 1, 1, 0, 0, 0) + #duration(0, 0, 0, [UnixTimestamp]),
    0  // UTC offset in hours
  )

The result is a datetimezone value. Display it in any specific zone by adding offsets, or normalize across the model by always storing UTC and converting only in the visual.

If your data source mixes timezones (some events in EST, some in PST), the cleanest approach is to convert everything to Unix timestamps at the source, store them as integers in the model, and convert to UTC datetimes in Power Query. Unix timestamps are timezone-free by design.

For a quick value check while building your report, paste any Unix timestamp into the free converter — it handles seconds and milliseconds automatically.

Try It Free — No Signup Required

Runs 100% in your browser. No data is collected, stored, or sent anywhere.

Open Free Unix Timestamp Converter

Frequently Asked Questions

How do I convert a Unix timestamp in Power BI?

Two places: in Power Query during data load (preferred), or in DAX as a calculated column. Power Query: #datetime(1970,1,1,0,0,0) + #duration(0,0,0,[Column]). DAX: DATE(1970,1,1) + Column/86400. Both produce a datetime from the Unix seconds value.

Should I convert in Power Query or DAX?

Power Query is almost always better. It happens at load time, the result is a regular column, and you get full date hierarchy support. DAX calculated columns recompute at refresh and consume model memory. Use DAX only when the conversion needs to depend on filter context.

How do I handle milliseconds in Power BI?

Divide by 1000 before the conversion. In Power Query: #duration(0, 0, 0, [UnixMs] / 1000). In DAX: DATE(1970,1,1) + Column/86400000. The 86400000 is milliseconds in a day.

Why does Power BI show the wrong time?

Power BI date columns have no timezone by default — they display whatever value was loaded. If your data source sent UTC and you assume local, the display will be wrong. Force timezone awareness by using DateTimeZone in Power Query and converting at the visual layer.

Can I convert a datetime back to Unix timestamp in DAX?

Yes: INT((Table[DateTime] - DATE(1970,1,1)) * 86400). This gives Unix seconds. For milliseconds, multiply by 86400000. The INT wrapper truncates fractional seconds because Unix timestamps are always integers.

Does Power BI support timezone conversion natively?

Partially. The DateTimeZone type carries an offset, and DateTime.AddZone applies one to a naive datetime. There is no built-in IANA timezone name support — for daylight savings handling across complex zones, you typically need to convert in the source database before loading into Power BI.

Launch Your Own Clothing Brand — No Inventory, No Risk