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.
Example diagram of inlunarweektodate() function
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
inlunarweektodate() function, no additional arguments
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
inlunarweektodate() function, period_no example
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
inlunarweektodate() function, first_week_day example
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
inlunarweektodate() function, chart object example
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.
When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. The information does not usually directly identify you, but it makes the site work as you expect it to and can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer.
Privacy & Cookie Notice
Manage Consent Preferences
Strictly Necessary Cookies
Always Active
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work.
Functional Cookies
These cookies enable the website to provide enhanced functionality and personalization. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies, then some or all of these services may not function properly. These cookies do not typically store personal information enabling us to identify you, but are based on uniquely identifying your browser and internet device.
Performance Cookies
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site and make it easier to navigate. For example, they help us to know which pages are the most and least popular and see how visitors move around the site. When analyzing this data it is typically done on an aggregated (anonymous) basis.
Advertising Cookies
These cookies may be set through our site by our advertising partners to build a profile of your interests and show you relevant advertisements on other sites. They do not typically store personal information enabling us to identify you, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less relevant advertising.