Creates a DateTime from milliseconds since 1970, 00:00:00 GMT. This reference point — midnight on January 1, 1970 UTC — is known as the Unix epoch, and is a standard way many systems and APIs represent timestamps as a single large number rather than a formatted date string.
| Property | Type | Description |
|---|---|---|
| DateTimeMilliseconds | Number | The number of milliseconds elapsed since January 1, 1970, 00:00:00 GMT. Example: 1457586000000 will create a date representing 03/10/2016. |
| CenturyIncluded | Boolean | This property is false by default. When set to true, an extra leading digit is expected in the timestamp — for example, 11457586000000 (note the extra 1) will create the same date as the example above. This accommodates source systems that prepend a century indicator digit to their epoch values. |
Understanding Unix Epoch Timestamps
The Unix epoch counts every millisecond that has passed since 1970-01-01T00:00:00 GMT. This is how many modern APIs, databases, and logging systems store timestamps internally — as a single large integer — because it avoids ambiguity around date formats, timezones, and locale differences.
| DateTimeMilliseconds | Resulting DateTime (UTC) |
|---|---|
0 |
1970-01-01T00:00:00 (epoch origin) |
1457586000000 |
2016-03-10T05:00:00 |
1718445900000 |
2024-06-15T13:45:00 |
The CenturyIncluded Property
Some legacy or proprietary systems prepend a single digit to their epoch millisecond values as a century marker (typically 1 for the 21st century). Setting CenturyIncluded to true tells the action to strip that leading digit before performing the conversion, ensuring the result is correct.
| CenturyIncluded | Input Value | Interpreted As | Result |
|---|---|---|---|
false (default) |
1457586000000 |
Standard epoch ms | 2016-03-10 |
true |
11457586000000 |
Leading 1 stripped → 1457586000000
|
2016-03-10 |
If your source value has 14 digits and CenturyIncluded is left as false, the result will be an incorrect date far in the future — so it's important to know whether your source system uses this convention.
Typical Use Case
Processing timestamps from a REST API or JSON payload
Many modern APIs return timestamps as epoch milliseconds. For example, an order management system might return:
"order_timestamp": 1718445900000
Rather than parsing a date string, you can feed this value directly into CreateDateTimeFromMilliseconds to produce a proper DateTime, which can then be used downstream in actions like CalculateDuration, AddDateTimeWithFields, or CreateStringFromDateTime to format it for an outbound EDI document or target system.
| Property | Value |
|---|---|
| DateTimeMilliseconds | 1718445900000 |
| CenturyIncluded | false |
| Result | 2024-06-15T13:45:00 |
Notes
- If
DateTimeMillisecondsis null, the action returns null — include a null check in your ruleset if the source value may be absent. - The conversion is performed in UTC (GMT). If your integration requires local time, apply a timezone offset using AddDateTimeWithFields after conversion.
- For timestamps provided as a formatted date string (e.g.
"2024-06-15"), use CreateDateTimeFromString instead. For assembling a DateTime from discrete numeric fields, use CreateDateTime.
Related Actions
- CreateDateTime: build a DateTime from individual year, month, day, hour, minute, and second values.
- CreateDateTimeFromString: convert a formatted date/time string into a DateTime.
- AddDateTimeWithFields: shift the resulting DateTime by a specified interval (e.g. add hours to adjust for timezone).
- CreateStringFromDateTime: format the resulting DateTime as a string for output.
Comments
0 comments
Please sign in to leave a comment.