This command displays calendar information similar to the Linux ncal command. It implements the same functionality, including the ability to display multiple months, years, day of the year and month forward and month previous by one year.
But in addition, the command can do a whole lot more:
- Display a calendar in any supported culture. Month and day names are displayed in the appropriate language for the specified culture and the appropriate calendar is used (e.g. Gregorian, Persian), along with appropriate DateTimeFormat information (e.g. default first day of the week).
- As well as display the primary calendar (used by each culture), also display optional calendars. These are Hijri (Islamic or Muslim), Hebrew, Japanese (Solar), Korean (Solar) and Taiwanese (Solar) calendars. In addition, the non-optional calendars are supported. These are calendars not used by any culture, but still observed for religious, scientific or traditional purposes. Namely the Julian and Chinese, Japanese, Korean and Taiwanese lunar calendars. (Note: Only the current era is supported).
- Specify the first day of the week (Friday through Monday). The specified or current culture setting is used by default. Friday through Monday are supported because all cultures use one of these days.
- Display one to six months in a row, when multiple months are displayed (the default is 4).
- Highlight the year and month headings, week numbers and todays date using a specified colour.
It is highly recommended that Windows Terminal is used with an appropriate font to ensure that ISO Unicode character sets are both available and are displayed correctly. With other consoles, like Visual Studio Code and the default PowerShell console, some fonts might not display correctly and with extended Unicode character sets, calendars may appear misaligned.
Note: From version 1.22.10352.0 (Feb 2025) of Windows Terminal, grapheme clusters are now supported and are turned on by default. A grapheme cluster is a single user-perceived character made up of multiple code points from the Unicode Standard, introduced in .NET 5. Whilst this is considered the correct method for handling and displaying Unicode character sets, PowerShell doesn't support grapheme clusters and thus, calandars in ncal appear misaligned. This can be remedied, in the short term, by disabling grapheme cluster support in Settings > Compatibility > Text measurement mode, selecting "Windows Console" and then restarting the Windows Terminal.
Use the following command to see the available cultures on your system and pass a culture name to ncal with the -Culture parameter.
Get-Culture -ListAvailableSimilar to the Linux cal command with similar functionality extras, as above. Displaying full day names and week numbers are not supported with cal, but everything else works the same way.
Display today's date in any of the calendars supported by .NET Framework. By default, today's date for every supported calendar is shown. The Gregorian calendar is always shown, to compare with the specified calendar(s).
ncal and cal have been tested with over 800 cultures and work well providing that Windows Terminal is used together with a font that supports Unicode character sets. (I have been using the Lilex Nerd Font during the development of ncal). In addition, calendars not primarily used by a culture are supported. These include the Julian, Hijra (Islamic or Muslim calendar), Chinese lunar, Hebrew and several other calendars which are observed in many parts of the world for religious or scientific purposes. Note that the Julian calendar uses an ISO 1806 culture because, well I live in a country that follows this standard. With the Asian lunar calendars, the 13th month can be specified as the required month, but read later for problems supporting non-default calendars.
- All culture based calendars display well, except for cultures using the Chakma language (ccp, ccp-BD and ccp-IN) which is misaligned because of varying lengths in the Unicode characters. Log an issue if this affects you.
- Some languages have really long month and day names. Rather than attempting to shorten these, they have been left culturally correct. Again, if this is affecting you and you can help with the specifics, I'd be prepared to look at this. For cultures that use extended Unicode character sets, I will not attempt to shorten names. In the mean time, you can set -MonthInRow (or -r) to 1.
- The non-default calendars have no DateTimeFormat properties of their own. So the culture that makes the most sense is used. For some calendars, this is partially ok; for example the ar-SA (Saudi Arabia) culture uses the same month names as the Hijri (Islamic or Muslim) calendar. But for other calendars, like Hebrew, they use different month names from the closest culture (in this case, the he-IL (Israel) culture uses the Gregorian calendar and has different month names in Hebrew to the Hebrew calendar). I suspect this is true for other calendars too. This also affects week numbers and is especially noticeable with the Asian lunar calendars in years that have 13 months. The Julian, Hijri and Hebrew calendars are also affected. In these cases, displaying week numbers is not supported. The Asian solar calendars are ok.
- Some lunar calendars have 13 months in some years. The thirteenth month displays ok when a year is specified, but for the same reason as above, this month has no month name; the DateTimeFormat for the closest culture uses Gregorian which has twelve months only. In these situations, the month name will be shown as '13'. In summary, I don't think .NET Framework supports the none default calendars, with respect to DateTimeFormat, very well. (Unless I am missing something).
Here are some examples of ncal usage:









