TODAY retrieves the current system date as set in the operating system. TIME retrieves the current system time as set in the operating system. CURRENTDATETIME retrieves the current date and time in the DATETIME format, which is stored in UTC international time (formerly referenced as GMT or Greenwich Mean Time) and then displayed in local time. If we are using the Windows client, this uses the time in the NAV Client. If the system operates in multiple time zones at one time, search Microsoft Dynamics NAV Help on time zone for several references on how to deal with multiple time zones.

The syntax for each of these is as follows:

DateField := TODAY;
TimeField := TIME;
DateTimeField := CURRENTDATETIME;

These are often used for date- and time-stamping transactions or for filling in default values in fields of the appropriate data type. For data entry purposes, the current system date can be entered by simply typing the letter T or the word TODAY in the date entry field (this is not a case-sensitive entry). NAV will automatically convert this entry to the current system date.

The undefined date in NAV 2015 is represented by the earliest valid DATETIME in SQL Server, which is January 1, 1753 00:00:00:000. The undefined date in NAV is represented as 0D (zero D, as in Days), with subsequent dates handled through December 31, 9999. A date outside this range will result in a run-time error.

The Microsoft Dynamics NAV undefined time (0T) is represented by the same value as an undefined date (0D). If a two digit year is entered or stored, and has a value of 30 to 99, it is assumed to be in the 1900s. If the two digit date is in the range of 00 to 29, then it is treated as a 2000s date.

Many standard NAV routines default dates to Work Date rather than to the system date. When a user logs into the system, the Work Date is initially set equal to the System Date. But at any time, the operator can set the Work Date to any date by accessing the Application Menu, clicking on Set Work Date…, and then entering the new Work Date.

The user can also click on the Work Date displayed in the status bar at the bottom of the RTC. The following screenshot shows the Set Work Date screen:

For data entry purposes, the current Work Date can be entered by the operator by simply typing the letter w or W, or the word WORKDATE, in the date entry field. NAV will automatically convert that entry to the current Work Date.

The syntax for getting the current WorkDate value from within the C/AL code is as follows:

DateField := WORKDATE;

The syntax for setting the WorkDate to a new date from within the C/AL code is as follows:

WORKDATE(newdate);

DATE2DMY allows us to extract the sections of a date (Day of the month, Month, and Year) from a Date field. The syntax is as follows:

IntegerVariable := DATE2DMY ( DateField, ExtractionChoice )

The IntegerVariable and DateField fields are just what their names imply. The ExtractionChoice parameter allows us to choose which value (Day, Month, or Year) will be assigned to the IntegerVariable. The following table provides the DATE2DMY extraction choices:

DATE2DWY allows us to extract the sections of a date (Day of the week, Week of the year, and Year) from a Date field in exactly the same fashion as DATE2DMY. The ExtractionChoice parameter allows us to choose which value (Day, Week, or Year) will be assigned to the IntegerVariable, as shown in the following table:

DMY2DATE allows us to create a date from integer values (or defaults) representing the day of the month, month of the year, and the four-digit year. If an optional parameter (MonthValue or YearValue) is not specified, the corresponding value from the System Date is used. The syntax is as follows:

DateVariable := DMY2DATE ( DayValue [, MonthValue] [, YearValue] )

The only way to have the function use the Work Date values for Month and Year is to extract those values and then use them explicitly. An example is as follows:

DateVariable := DMY2DATE(22,DATE2MDY(WORKDATE,2),DATE2MDY(WORKDATE,3))

DWY2DATE operates similarly to DMY2DATE; allowing us to create a date from integer values representing the day of the week (from 1 to 7 representing Monday to Sunday), week of the year (from 1 to 53) followed by the four-digit year. The syntax is as follows:

DateVariable := DWY2DATE ( DayValue [, WeekValue] [, YearValue] )

An interesting result can occur for week 53 because it can span two years. By default, such a week is assigned to the year in which it has four or more days. In that case, the year of the result will vary depending on the day of the week in the parameters (in other words, the year of the result may be one year greater than the year specified in the parameters). This is a perfect example of why thorough testing of our code is always appropriate.

CALCDATE allows us to calculate a date value assigned to a Date data type variable. The calculation is based on a Date Expression applied to a Base Date (Reference Date). If we don't specify a BaseDateValue, the current system date is used as the default date. We can specify the BaseDateValue either in the form of a variable of data type Date or as a Date constant.

The syntax for CALCDATE is as follows:

DateVariable := CALCDATE ( DateExpression [, BaseDateValue])

There are a number of ways in which we can build a DateExpression. The rules for the CALCDATE function DateExpression are similar to the rules for DateFormula described in Chapter 3, Data Types and Fields.

If there is a CW, CM, CP, CQ, or CY (Current Week, Current Month, Current Period, Current Quarter, or Current Year) parameter in an expression, then the result will be evaluated based on the BaseDateValue. If we have more than one of these in our expression, the results are unpredictable. Any such expression should be thoroughly tested before releasing to the users.

If our Date Expression is stored in a DateFormula variable (or a Text or Code variable with the DateFormula property set to Yes), then the Date Expression will be language independent. Also, if we create our own Date Expression in the form of a string constant within our inline C/AL code, surrounding the constant with < > delimiters as part of the string, it will make the constant language independent. Otherwise, the Date Expression constant will be language dependent.

Regardless of how we have constructed our DateExpression, it is important to test it carefully and thoroughly before moving on. Incorrect syntax will result in a runtime error. One easy way to test is by using a Report whose sole task is to evaluate our expression and display the result. If we want to try different Base Dates, we can use the Request Page, accept the Base Date as input, then calculate and display the DateVariable in the OnValidate trigger.

Some sample CALCDATE expression evaluations are as follows: