Wolfram Computation Meets Knowledge

New in the Wolfram Language: ISO Dates and More

A classic problem in numerical date notation is that various countries list year, month, and day in different orders, which was one of the motivations for the introduction of the ISO-8601 date element and interchange formats (Randall Monroe has a nice summary in this xkcd comic). In the upcoming release of the Wolfram Language, we’ve added built-in support for these ISO date formats:

DateString ISODate; DateString ISODateTime

The ISO specification also provides some alternative date representations, such as week dates (year, week of year, and day of week) and ordinal dates (year and day of year):

DateString ISOWeekDate; DateString ISOOrdinalDate

In addition to the ISO-8601 formats, we’ve added two new numerical representations of time to the Wolfram Language, UnixTime, which gives the number of seconds since January 1, 1970, 00:00:00 UTC, and JulianDate, which gives the number of days since November 24, 4714 BCE, 12:00:00 UTC:

UnixTime and JulianDate

UnixTime is a variation of AbsoluteTime, which gives the number of seconds since January 1, 1900, 00:00:00 in your local time zone; however, one important difference is that the output time zone is always in Coordinated Universal Time (UTC), which is one reason it’s frequently used for time stamps. FromUnixTime takes a UnixTime value and returns a corresponding DateObject:


JulianDate is frequently used in astronomical calculations, such as in the following approximation of SiderealTime:


The Wolfram Language has a built-in (higher resolution) SiderealTime function, which I can compare with the approximation above:

UnitConvert SiderealTime

JulianDate can also be useful in representing many simple calendar systems, such as the Egyptian solar calendar, which has 365 days in every year, twelve 30-day months (plus one 5-day month), and no leap years. You can use the following function to get an Egyptian calendar date (which uses February 18, 747 BCE as its epoch date):


As a quick sanity check, I’ll put in the epoch date to verify I’m getting the correct results:

Verifying results with epoch date

And the inverse operation is simple: just add the years, months, and days to the epoch, and FromJulianDate constructs an appropriate DateObject expression:

Using FromJulianDate to construct a DateObject expression

Once again I can verify our formula by using the calendar epoch:

Verifying formula by using calendar epoch

And I can do the same with a more recent date, such as Today:

Using Today function

This works with any representation of dates in the Wolfram Language:
Representation of dates in Wolfram Language

These are just some of the uses for the new date and time features in the Wolfram Language. Once available, share your examples through Wolfram Tweet-a-Program or Wolfram Community! Stay tuned!


Join the discussion

!Please enter your comment (at least 5 characters).

!Please enter your name.

!Please enter a valid email address.


  1. You have wrote “however, one important difference is that the output time zone is always in Coordinated Universal Time (UTC)” but int the Documentation I have found “UnixTime[] returns the number of seconds that have elapsed since {1970, 1, 1, 0, 0, 0.} Greenwich Mean Time (GMT)”. So, UTC or GMT?