Introduction
All editions of the Quagensia® Desktop Application have excellent support for data types that represent dates, times, and combined “date and time” values.
Since different trading platforms support different date and time data types, different editions of Quagensia also support different date and time data types.
Dates and Times in Quagensia N Edition
Quagensia N Edition supports three different date and time data types: “Time of Day”, “Date (Without Time of Day)”, and “Date and Time”.
Quagensia N Edition generates NinjaScript® code for NinjaTrader®. Dates and times in NinjaScript® are handled by the “DateTime” data type of the C# programming language. Variables, input parameters, and expressions of all three date and time data types supported by Quagensia N Edition end up being stored and processed as C# DateTimes in the generated code.
The reason why Quagensia N Edition supports “Time of Day” and “Date (Without Time of Day)” data separately from “Date and Time” data is that it makes it easier to work with dates (without time of day components) and times (without date components).
Dates and Times in Quagensia T Edition
Quagensia T Edition supports eight different date and time data types belonging to three different “date and time models”:
- “EL Date” and “EL Time”, which are part of the “EL Date and EL Time” model of dates and times.
- “Julian Date (Without Time of Day) (Decimal Format)”, “Julian Time of Day (Decimal Format)”, and “Julian Date and Time (Decimal Format)”, which are part of the “Julian (Decimal Format)” model of dates and times.
- “Date (Without Time of Day) Object Reference (Highly Advanced)”, “Time of Day Object Reference (Highly Advanced)”, and “Date and Time Object Reference (Highly Advanced)”, which are part of the “DateTime Object Reference (Highly Advanced)” model of dates and times.
Below is a discussion of the three different “date and time models” of date and time data types, and when you might want to use data types of one date and time model over another.
“EL Date” and “EL Time”, the two data types of the “EL Date and EL Time” model of dates and times
The “EL Date” and “EL Time” data types are good choices for your Quagensia T Edition strategies for when you either want your dates and times to be easy to read in EasyLanguage® code or you want your TradeStation® strategies to have date and time input parameters, so long as you don’t care about the seconds components of times and don’t mind the fact that you cannot store an entire date and time in a single “EL Date” or “EL Time” object.
The “EL Date” and “EL Time” data types store dates and times separately as whole numbers, specifically as “int” (i.e. “32-bit signed integer”) values.
One advantage of the “EL Date” and “EL Time” data types when compared to the other six date and time data types is that they are the only two of the eight date and time data types supported by Quagensia T Edition that are easy to read in EasyLanguage® code. For instance, the date “January 30, 2021”, when stored as a whole number that represents an “EL Date”, is the number 1210130. The first three digits, “121”, represent the year that is 121 years later than 1900, i.e. 2021. The next two digits represent the number of the month from 1 to 12, where 01 is January, 02 is February, and 12 is December, and where single digit months (months between 01 and 09) are padded with a 0 on the left side. The final two digits are the day of the month, where the first 9 days of the month are padded with a 0 on the left side, like “09” for the 9th day of the month. “EL Times” are even easier to read. For instance, 2:30 PM is stored as the whole number 1430, and 2:30 AM is stored as 0230.
Another nice thing about the “EL Date” and “EL Time” data types is that since they are stored as simple whole numbers, they can be used as the data types of input parameters in your TradeStation® strategies, unlike the three DateTime Object Reference data types. And since the format rules for the whole numbers that represent “EL Date” and “EL Time” input parameters are easy to remember, read, and type, this makes “EL Date” and “EL Time” better choices for the data types of your TradeStation® strategies’ input parameters than the three Julian Date and Time (Decimal Format) data types, whose data are stored as decimal numbers that are much more difficult to read and understand.
One negative about the “EL Time” data type is that it only has an hours and a minutes component; it does not have a seconds component.
Another negative thing about “EL Date” and “EL Time” is that, as previously mentioned, they each store part of a date and time, but neither can store an entire date and time. It is often significantly more convenient to look at a date and time as a single piece of data, for instance when looking at the date and time of a price bar as a single date and time and comparing that date and time to another date and time value.
“Julian Date (Without Time of Day) (Decimal Format)”, “Julian Time of Day (Decimal Format)”, and “Julian Date and Time (Decimal Format)”, the three data types of the “Julian (Decimal Format)” model of dates and times
The three Julian (Decimal Format) data types are good choices for your Quagensia T Edition strategies for when you want to store an entire date and time in a single value or if you care about the seconds components of times, so long as you don’t need your dates and times to be easy to read in either EasyLanguage® code or easy to read and enter as input parameters to your TradeStation® strategies. Non-advanced users trying to decide between Julian (Decimal Format) data types and DateTime Object Reference data types should choose Julian (Decimal Format) data types.
The “Julian Date (Without Time of Day) (Decimal Format)”, “Julian Time of Day (Decimal Format)”, and “Julian Date and Time (Decimal Format)” data types store the value of a date, time, or date and time as a single decimal number, specifically as a “double” (i.e. “double-precision floating-point”) value.
One advantage of the Julian (Decimal Format) data types when compared with the “EL Time” data type is that the time of day component of both the “Julian Time of Day (Decimal Format)” and the “Julian Date and Time (Decimal Format)” data types include the seconds component, unlike the times held in “EL Time” objects.
Another advantage of the Julian (Decimal Format) data types is that an entire date and time can be stored in an variable of the “Julian Date and Time (Decimal Format)” data type, because it is just a decimal number in the EasyLanguage® code, where the number to the left of the decimal place is the number of days since January 1, 1900 and the number to the right of the decimal place is the fraction of a day represented by a given time of day.
However, the decimal format of the Julian (Decimal Format) data types is sometimes a disadvantage when compared to the easy-to-read “EL Date” and “EL Time” formats, as described above, because it takes a calculator to be able to manually interpret the date and time that is represented by a decimal number encountered in the EasyLanguage® code. For instance, the number 44226.60416666666424 represents the date and time value of “January 30, 2021 2:30:00 PM”, because January 30, 2021 is evidently 44,226 days later than January 1, 1900, and 2:30 PM is evidently 60.416666666424% of the way through the day, starting at midnight. One consequence of this difficulty in reading and understanding decimal numbers that represent Julian (Decimal Format) date and time objects is that while, unlike the three DateTime Object Reference data types, it is technically possible to use them as the data types of input parameters in your TradeStation® strategies, the input parameters will require decimal numbers to be entered to represent a given date, time, or date and time, and this is much more difficult than entering nicely formatted, easy-to-remember whole numbers to represent dates and times in “EL Date” and “EL Time” input parameters.
The three Julian (Decimal Format) date and time data types are similar to the three DateTime Object Reference data types in that they can store a date and a time in a single value, and because the time of day components of data types of both of these date and time models have a seconds component, but the Julian (Decimal Format) data types have the following important advantages over the three DateTime Object Reference data types:
- Unlike values of the three DateTime Object Reference data types, values of the Julian (Decimal Format) data types can be used in arrays, times series, and input parameters of TradeStation® strategies. Data of DateTime Object Reference data types can, however, be stored in Quagensia T Edition Lists, which are outputted as EasyLanguage® vectors, which makes the lack of array support less critical. Also, Quagensia T Edition makes it really easy to convert between Julian (Decimal Format) date and time objects and DateTime Object Reference objects, so if you are an advanced user who really wants to use DateTime Object References but also needs to use dates and times with arrays, times series, or input parameters of TradeStation® strategies, you can use Julian (Decimal Format) date and time objects in these places where DateTime Object Reference objects are prohibited, so long as you are willing to convert the DateTime Object Reference objects into Julian (Decimal Format) date and time objects using the easy-to-use Quagensia T Edition date and time conversion functions. For most users, Julian (Decimal Format) dates and times are a better choice, however, since while it is easy to convert between DateTime Object Reference objects and Julian (Decimal Format) date and time objects, its just another unnecessary step that could be avoided if you use Julian (Decimal Format) date and time data types instead of the DateTime Object Reference data types in all places where you have the choice of using either a Julian (Decimal Format) data type or a DateTime Object Reference data type.
- When you use DateTime Object Reference data types, you expose yourself to serious logic errors that can occur when a variable of a DateTime Object Reference data type is set to another variable of a DateTime Object Reference data type. When you use Julian (Decimal Format) data types, there is no risk of this problem occurring. Please see the discussion in the next section about this to understand why this difference alone makes Julian (Decimal Format) date and time data types a better choice for non-advanced users.
“Date (Without Time of Day) Object Reference (Highly Advanced)”, “Time of Day Object Reference (Highly Advanced)”, and “Date and Time Object Reference (Highly Advanced)”, the three data types of the “DateTime Object Reference (Highly Advanced)” model of dates and times
The three “DateTime Object Reference (Highly Advanced)” date and time data types are for advanced users only, since Quagensia T Edition makes it easy to accomplish the same things with Julian (Decimal Format) date and time data types that you can do with “DateTime Object Reference (Highly Advanced)” date and time data types, Julian (Decimal Format) date and time data types have the added benefit of being allowed in arrays, in time series, and in the input parameters of TradeStation® strategies, and because when you use “DateTime Object Reference (Highly Advanced)” data types, you expose yourself to serious logic errors that can occur when a variable of a DateTime Object Reference data type is set to another variable of a DateTime Object Reference data type.
Advanced users will still find value in being able to use the three “DateTime Object Reference (Highly Advanced)” date and time data types of Quagensia T Edition. Specifically, when an advanced user tries to accomplish something with Julian (Decimal Format) date and time data types and find these data types non-ideal for their use case, the advanced user may find the “DateTime Object Reference (Highly Advanced)” date and time data types of Quagensia T Edition to be a better fit for their specific challenge.
The rest of this section will explain the following statement, which was made above:
“when you use DateTime Object Reference data types, you expose yourself to serious logic errors that can occur when a variable of a DateTime Object Reference data type is set to another variable of a DateTime Object Reference data type”
Whenever you create an internal variable of one of the three DateTime Object Reference data types, including an internal variable that is a List of objects of one of these types, a very large warning message appears which explains the statement above and provides specific instructions to reduce this specific risk. This very large warning message is slightly different based on which of the three DateTime Object Reference data types you choose. If you choose the “Date and Time Object Reference (Highly Advanced)” data type, you will see a very large warning message that looks something like the one shown below, which will also serve as the end of this section:
WARNING: THE “DATE AND TIME OBJECT REFERENCE” DATA TYPE IS FOR ADVANCED USERS ONLY. NON-ADVANCED USERS SHOULD USE THE “JULIAN DATE AND TIME (DECIMAL FORMAT)” DATA TYPE INSTEAD.
This is because whenever one Date and Time Object Reference variable is set from another Date and Time Object Reference variable, regardless of whether this occurs via a “Set a Variable” action, via a function that adds items to a List or modifies an item in a List, or via another function that manipulates Lists or does anything that sets one variable from another variable, not only will both Date and Time Object Reference variables have the same value, but they will also point to the same Date and Time Object Reference object in memory and therefore share the same Date and Time Object Reference object, because the Date and Time Object Reference data type is a “reference type”, not a “value type”.
A side effect of this is that modifying one of the date or time components (year, month, day of month, hours, minutes, or seconds, or any property, like EL Date, EL Time, or Value, that modifies any of these date and time components) of this shared object through either of the two variables will change the value of that date or time component of the other variable as well since the date or time component of the shared object to which both variables point was changed.
You have two ways to change this behavior when working with dates and times:
First, you can use the Julian Date and Time (Decimal Format) data type instead of the Date and Time Object Reference data type, because Julian dates and times are stored as simple decimal numbers, which are “value types”, not “reference types”, and therefore never share the same object in memory, so don’t have the problem described above. This is the safest option.
Second, if you still want this variable to use the Date and Time Object Reference data type, despite the risks described above, be aware that the way to set one Date and Time Object Reference to the value of another Date and Time Object Reference variable without the two variables sharing the same object is to use the “Copy Value from One Date and Time Object Reference To Another One” action function located in the “More Actions >> Dates and Times >> Date and Time Object Reference >> Create or Copy” context menu subfolder accessible by clicking anywhere that an action is allowed to be placed. Be warned that some Quagensia T Edition functions that accept variables of the Date and Time Object Reference data type as input parameters, including Lists of Date and Time Object Reference variables, which do things like copy, sort, and otherwise manipulate Lists, will still end up producing two or more variables that point to the same shared object in memory. So even if you are careful to use the special “Copy Value from One Date and Time Object Reference To Another One” function mentioned above, another function that you did not create may end up creating the problematic scenario described above. This is why we recommend that all non-advanced users use the Julian Date and Time (Decimal Format) instead, since not only do you not need to be careful about the problem described above when setting Julian Date and Time (Decimal Format) variables, but you also don’t need to worry about functions that you did not create causing the same problem.
Quagensia N & T Editions have built-in functions for working with dates and times.
The no-code functions for working with dates and times that are built into Quagensia N & T Editions are listed below with links to their help pages. Each of these functions is displayed in the same subfolder in which you can find it in the Quagensia Desktop Application’s Algo Explorer and in the context menu that appears when you click on a location on your Quagensia Algo’s workspace where the expression function or action function is allowed to be used.
The next section lists the expression functions for working with dates and times that are built into Quagensia N Edition. You can also scroll down to the list of expression functions for working with dates and times that are built into Quagensia T Edition further down on this page. Quagensia T Edition also has action functions for working with dates and times but most of these are highly advanced. You can view these (mostly) highly advanced action functions for Quagensia T Edition by scrolling down to the last section on this help page.
