This function determines if timestamp lies inside the
lunar week
containing base_date. Lunar weeks in Qlik Sense are defined by counting January 1 as the first day of the week., Apart from the final week of the year, each week 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 inlunarweek() function determines which lunar week the base_date falls into. It then returns a Boolean result once it has determined whether each timestamp value occurs during the same lunar week as the base_date.
When to use it
The inlunarweek() function returns a Boolean result. Typically, this type of function will be used as a condition in an IF expression. This would return an aggregation or calculation dependent on whether the date evaluated occurred during the lunar week in question.
For example, the inlunarweek() function can be used to identify all equipment manufactured in a particular lunar week.
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.
Function examples
Example
Result
inlunarweek('01/12/2013', '01/14/2013',
0)
Returns TRUE, since the value of timestamp, 01/12/2013, falls in the week 01/08/2013 to 01/14/2013.
inlunarweek('01/12/2013', '01/07/2013',
0)
Returns FALSE, since the base_date01/07/2013 is in the lunar week defined as 01/01/2013 to 01/07/2013.
inlunarweek('01/12/2013', '01/14/2013',
-1)
Returns FALSE. Specifying a value of period_no as -1 shifts the week to the previous week, 01/01/2013 to 01/07/2013.
inlunarweek('01/07/2013', 01/14/2013',
-1)
Returns TRUE. In comparison with the previous example, the timestamp is in the following week, after into account the shift backwards.
inlunarweek('01/11/2006', '01/08/2006',
0, 3)
Returns FALSE. Specifying a value of 3 for first_week_day means that the start of the year is calculated from 01/04/2013. Therefore, the value of base_date falls in the first week, and the value of timestamp falls in the week 01/11/2013 to 01/17/2013.
The inlunarweek() 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.
Load the data and open a sheet. Create a new table and add these fields as dimensions:
date
in_lunar_week
Results table
date
in_lunar_week
1/5/2022
0
1/6/2022
0
1/7/2022
0
1/8/2022
-1
1/9/2022
-1
1/10/2022
-1
1/11/2022
-1
1/12/2022
-1
1/13/2022
-1
1/14/2022
-1
1/15/2022
0
1/16/2022
0
1/17/2022
0
1/18/2022
0
1/19/2022
0
1/20/2022
0
1/21/2022
0
1/22/2022
0
1/23/2022
0
The in_lunar_week field is created in the preceding load statement by using the inlunarweek() function, then passing the following as the function's arguments:
The date field
A hard-coded date for January 10 as the base_date
Aperiod_no of 0
Because lunar weeks begin on January 1, January 10 would fall in the lunar week that begins on January 8 and ends on January 14. 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 2 - period_no
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 date field has been provided in the DateFormat system variable (MM/DD/YYYY) format.
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 lunar weeks after January 10.
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/5/2022
0
1/6/2022
0
1/7/2022
0
1/8/2022
0
1/9/2022
0
1/10/2022
0
1/11/2022
0
1/12/2022
0
1/13/2022
0
1/14/2022
0
1/15/2022
0
1/16/2022
0
1/17/2022
0
1/18/2022
0
1/19/2022
0
1/20/2022
0
1/21/2022
0
1/22/2022
-1
1/23/2022
-1
In this instance, because a period_no of 2 was used as the offset argument in the inlunarweek() function, the function defines the week beginning on January 22 as the lunar week to validate transactions against. Therefore, any transaction that takes place between the January 22 and January 28 will return a Boolean result of TRUE.
Load the data and open a sheet. Create a new table and add these fields as dimensions:
date
in_lunar_week
Results table
date
in_lunar_week
1/5/2022
0
1/6/2022
-1
1/7/2022
-1
1/8/2022
-1
1/9/2022
-1
1/10/2022
-1
1/11/2022
-1
1/12/2022
-1
1/13/2022
0
1/14/2022
0
1/15/2022
0
1/16/2022
0
1/17/2022
0
1/18/2022
0
1/19/2022
0
1/20/2022
0
1/21/2022
0
1/22/2022
0
1/23/2022
0
In this instance, because the first_week_date argument of 5 is used in the inlunarweek() function, it offsets the start of the lunar week calendar to January 6. Therefore, January 10 falls in the lunar week beginning on January 6 and ending on January 12. Any transaction that falls between these two dates will return a Boolean value of TRUE.
Example 4 - Chart object
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 date field has been provided in the DateFormat system variable (MM/DD/YYYY) format.
However, in this example, the unchanged dataset is loaded into the application. The calculation that determines whether the transactions took place in the same lunar week as 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.
To calculate whether a transaction takes place in the lunar week that contains January 10, create the following measure:
= inlunarweek(date,'01/10/2022', 0)
Results table
date
=inlunarweek(date,'01/10/2022', 0)
1/5/2022
0
1/6/2022
0
1/7/2022
0
1/8/2022
-1
1/9/2022
-1
1/10/2022
-1
1/11/2022
-1
1/12/2022
-1
1/13/2022
-1
1/14/2022
-1
1/15/2022
0
1/16/2022
0
1/17/2022
0
1/18/2022
0
1/19/2022
0
1/20/2022
0
1/21/2022
0
1/22/2022
0
1/23/2022
0
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 that included January 12 were defective. The end user would like a chart object that displays, by lunar week name, the status of whether the products manufactured were ‘defective’ or ‘faultless’ and the cost of the products manufactured in that month.
The inlunarweek() function returns a Boolean value when evaluating the manufacturing dates of each of the products. For any product manufactured in the lunar week that contains January 10, the inlunarweek() function returns a Boolean value of TRUE and marks the products as ‘Defective’. For any product returning a value of FALSE, and therefore not manufactured in that week, 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.