This function finds if timestamp lies inside the
part of the lunar week up to and including the last millisecond of base_date. Lunar weeks in Qlik Sense are defined by counting January 1 as the first day of the week and, apart from the final week of the year, will contain exactly seven days.
In Qlik Sense, the Boolean true value is represented by -1, and the false value is represented by 0.
The inlunarweektodate() function acts as the end point of the lunar week. In contrast, the inlunarweek() function, determines which lunar week the base_date falls into. For example, if the base_date were January 5, any timestamp between January 1 and January 5 would return a Boolean result of TRUE, while dates on January 6 and 7, and later, would return a Boolean result of FALSE.
Arguments
Argument
Description
timestamp
The date that you want to compare with base_date.
base_date
Date that is used to evaluate the lunar week.
period_no
The lunar
week can be offset by period_no.
period_no is an integer, where the
value 0 indicates the lunar week which contains base_date.
Negative values in period_no indicate
preceding lunar weeks and positive values indicate succeeding lunar weeks.
first_week_day
An offset that may be greater than or less than zero. This changes the beginning of the year by the specified number of days and/or fractions of
a day.
When to use it
The inlunarweektodate() function returns a Boolean result. Typically, this type of function will be used as a condition in an IF expression. The inlunarweektodate() function would be used when the user would like the calculation to return an aggregation or calculation, dependent on whether the evaluated date occurred during a particular segment of the week in question.
For example, the inlunarweektodate() function can be used to identify all equipment manufactured in a particular week up to and including a particular date.
Function examples
Example
Result
inlunarweektodate('01/12/2013', '01/13/2013',
0)
Returns TRUE, since the value of the timestamp, 01/12/2013, falls in the part of the week 01/08/2013 to 01/13/2013.
inlunarweektodate('01/12/2013', '01/11/2013',
0)
Returns FALSE, since the value of the timestamp is later than the value of base_date, even though the two dates are in the same lunar week before 01/12/2012.
inlunarweektodate('01/12/2006', '01/05/2006',
1)
Returns TRUE. Specifying a value of 1 for period_no shifts the base_date forward one week, so the value of timestamp falls in the part of the lunar week.
The inlunarweektodate() function is often used in combination with the following functions:
This function is used to determine the lunar week number of the year in which an input date occurs.
Regional settings
Unless otherwise specified, the examples in this topic use the following date format: MM/DD/YYYY. The date format is specified in the SET DateFormat statement in your data load script. The default date formatting may be different in your system, due to your regional settings and other factors. You can change the formats in the examples below to suit your requirements. Or you can change the formats in your load script to match these examples. For more information, see Modifying regional settings for apps and scripts.
Default regional settings in apps are based on the user profile. These regional format settings are not related to the language displayed in the Qlik Cloud user interface. Qlik Cloud will be displayed in the same language as the browser you are using.
Open the Data load editor and add the load script below to a new tab.
The load script contains:
A dataset containing a set of transactions for the month of January, which is loaded into a table called Transactions. The default DateFormat system variable MM/DD/YYYY is used.
Create a fieldin_lunar_week_to_date, that determines which transactions took place in lunar week to date of January 10.
Load the data and open a sheet. Create a new table and add these fields as dimensions:
date
in_lunar_week_to_date
Results table
date
in_lunar_week_to_date
1/1/2022
0
1/4/2022
0
1/10/2022
-1
1/11/2022
0
1/12/2022
0
1/15/2022
0
1/17/2022
0
1/18/2022
0
1/19/2022
0
1/21/2022
0
1/23/2022
0
1/26/2022
0
1/27/2022
0
1/29/2022
0
1/31/2022
0
The in_lunar_week_to_date field is created in the preceding load statement by using the inlunarweektodate() function and passing the date field, a hard-coded date for January 10 as our base_date, and an offset of 0 as the function’s arguments.
Because lunar weeks begin on January 1, January 10 would fall in the lunar week that begins on January 8; and because we are using the inlunarweektodate() function, that lunar week would then end on the 10th. Therefore, any transactions that occur between those two dates in January would return a Boolean value of TRUE. This is validated in the results table.
The load script contains the same dataset and scenario as the first example. However, in this example, the task is to create a field, 2_lunar_weeks_later, that determines whether or not the transactions took place two weeks after the lunar week to date of January 1.
Load the data and open a sheet. Create a new table and add these fields as dimensions:
date
2_lunar_weeks_later
Results table
date
2_lunar_weeks_later
1/1/2022
0
1/4/2022
0
1/10/2022
0
1/11/2022
0
1/12/2022
0
1/15/2022
0
1/17/2022
0
1/18/2022
0
1/19/2022
0
1/21/2022
0
1/23/2022
-1
1/26/2022
0
1/27/2022
0
1/29/2022
0
1/31/2022
0
In this instance, the inlunarweektodate() function determines that the lunar week up to January 10 equates to three days (January 8, 9, 10). Since a period_no of 2 was used as the offset argument, this lunar week is shifted by 14 days. Therefore, this defines that three-day lunar week to include January 22, 23, and 24. Any transaction that takes place between January 22 and January 24 will return a Boolean result of TRUE.
Example 3 - first_week_day
Overview
Open the Data load editor and add the load script below to a new tab.
The load script contains:
The same dataset and scenario as the first example.
The default DateFormat system variable MM/DD/YYYY is used.
A first_week_date argument of 3. This sets lunar weeks to begin on January 3.
Load the data and open a sheet. Create a new table and add these fields as dimensions:
date
in_lunar_week_to_date
Results table
date
in_lunar_week_to_date
1/1/2022
0
1/4/2022
-1
1/10/2022
-1
1/11/2022
0
1/12/2022
0
1/15/2022
0
1/17/2022
0
1/18/2022
0
1/19/2022
0
1/21/2022
0
1/23/2022
0
1/26/2022
0
1/27/2022
0
1/29/2022
0
1/31/2022
0
In this instance, because the first_week_date argument of 3 is used in the inlunarweek() function, the first lunar week will be from January 3 to January 10. Because January 10 is also the base_date, any transaction that falls between these two dates will return a Boolean value of TRUE.
Example 4 - Chart object example
Overview
Open the Data load editor, and add the load script below to a new tab.
The load script contains the same dataset and scenario as the first example.
However, in this example, the unchanged dataset is loaded into the application. The calculation that determines whether the transactions took place in the lunar week up to January 10 is created as a measure in a chart object of the application.
Load the data and open a sheet. Create a new table and add this field as a dimension: date.
Create the following measure:
=inlunarweektodate(date,'01/10/2022', 0)
Results table
date
=inlunarweektodate(date,'01/10/2022', 0)
1/1/2022
0
1/4/2022
0
1/10/2022
-1
1/11/2022
0
1/12/2022
0
1/15/2022
0
1/17/2022
0
1/18/2022
0
1/19/2022
0
1/21/2022
0
1/23/2022
0
1/26/2022
0
1/27/2022
0
1/29/2022
0
1/31/2022
0
The in_lunar_week_to_date measure is created in the chart object by using the inlunarweektodate() function and passing the date field, a hard-coded date for January 10 as our base_date, and an offset of 0 as the function’s arguments.
Because lunar weeks begin on January 1, January 10 would fall in the lunar week that begins on January 8. Additionally, since we are using the inlunarweektodate() function, that lunar week would then terminate on the 10th. Therefore, any transactions that occur between those two dates in January would return a Boolean value of TRUE. This is validated in the results table.
Example 5 - Scenario
Overview
Open the Data load editor and add the load script below to a new tab.
The load script contains:
A dataset which is loaded into a table called Products.
Information consisting of product ID, manufacture date, and cost price.
It has been identified that due to equipment error, products that were manufactured in the lunar week of January 12 were defective. The issue was resolved on January 13. The end user would like a chart object that displays, by week, the status of whether the products manufactured ‘defective’ or ‘faultless’ and the cost of the products manufactured in that week.
The inlunarweektodate() function returns a Boolean value when evaluating the manufacturing dates of each of the products. For those that return a Boolean value of TRUE, it marks the products as ‘Defective’. For any product returning a value of FALSE, and therefore not made in the lunar week up to January 12, it marks the products as ‘Faultless’.
Aggregation
An aggregation is a calculation using multiple records in the source tables. Often it is a single field aggregated with a function such as sum, count, min, max, or average. For example, the sum of sales.
The term dataset is sometimes synonymous with table. It can refer to the original source table, the table after undergoing transformations, or the fact and dimension tables in a data mart.
It can also refer to a logical table, where there are several instance tables and views:
Current data
History, which holds previous versions of the table
A field contains values, loaded from a data source. At a basic level, a field corresponds to a column in a table. Fields are used to create dimensions and measures in visualizations.
A preceding load is a script construct that allows you to load from the following LOAD or SELECT statement without specifying that source. Preceding loads are often faster than resident loads.
The load script is a sequence of statements that defines what data to load and how to link the different loaded tables. It can be generated with the Data manager, or with the Data load editor, where it also can be viewed and edited.
A measure is a calculation base on one ore more aggregations. For example, the sum of sales is a single aggregation, while the sum of sales divided by the count of customers is a measure based on two aggregations.
Sheets are components of Qlik Sense apps. They present visualizations to app users so they can explore, analyze, and discover data. Sheets can be public or private.
A dimension is an entity used to categorize data in a chart. For example, the slices in a pie chart or the bars of a bar chart represent individual values in a dimension. Dimensions are often a single field with discrete values, but can also be calculated in an expression.
A dimension is a dataset in a data mart that forms part of the star schema. Dimension datasets hold the descriptive information for all related fields that are included in the fact table’s records. A few common examples of dimension datasets are Customer and Product. Since the data in a dimension dataset is often denormalized, dimension datasets have a large number of columns.