Date (YYYY-MM-DD, DD/MM/YYYY, MM.DD.YYYY)
Deprecated
Starting from v10.0.x, the Date YYYY-MM-DD, Date DD/MM/YYYY, and Date MM.DD.YYYY tokenization types are deprecated.
It is recommended to use the Datetime (YYYY-MM-DD HH:MM:SS MMM) token type instead of the Date YYYY-MM-DD, Date DD/MM/YYYY, and Date MM.DD.YYYY token types.
The Date token type supports date formats corresponding to the big endian, little endian, and middle endian forms. It protects dates in one of the following formats:
- YYYY<delim>MM<delim>DD
- DD<delim>MM<delim>YYYY
- MM<delim>DD<delim>YYYY
Where <delim> is one of the allowed separators: dot “.”, slash “/”, or dash “-”.
Table: Date Tokenization Type properties
Tokenization Type Properties | Settings | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
Name | Date | |||||||||||
Token type and Format | Date in big endian form, starting with the year (YYYY-MM-DD). Date in little endian form, starting with the day (DD/MM/YYYY). Date in middle endian form, starting with the month (MM.DD.YYYY). The following separators are supported: dot ".", slash "/", or dash "-". | |||||||||||
Tokenizer | Length Preservation | Minimum Length | Maximum Length | |||||||||
SLT_1_3 SLT_2_3 SLT_1_6 SLT_2_6 | Yes | 10 | 10 | |||||||||
Possibility to set Minimum/ maximum length | No | |||||||||||
Left/Right settings | No | |||||||||||
Internal IV | No | |||||||||||
External IV | No | |||||||||||
Return of Protected value | Yes | |||||||||||
Token specific properties | All separators, such as dot ".", slash "/", or dash "-" are allowed. | |||||||||||
Supported range of input dates | From “0600-01-01” to “3337-11-27” | |||||||||||
Non-supported range of Gregorian cutover dates | From "1582-10-05" to "1582-10-14" | |||||||||||
The following table shows examples of the way in which a value will be tokenized with the Date token.
Table: Examples for Tokenization of Date
| Input Values | Tokenized Values | Comments |
|---|---|---|
| 2012-02-29 2012/02/29 2012.02.29 | 2150-02-20 2150/02/20 2150.02.20 | Date (YYYY-MM-DD) token is used. All three separators are successfully accepted. They are treated as delimiters not impacting tokenized value. |
| 31/01/0600 | 08/05/2215 | Date (DD/MM/YYYY) token is used. Date in the past is tokenized. |
| 10.30.3337 | 09.05.2042 | Date (MM.DD.YYYY) token is used. Date in the future is tokenized. |
| 2012:08:24 1975-01-32 | Token is not generated due to invalid input value. Error is returned. | Date (YYYY-MM-DD) token is used. Input values with non-supported separators or with invalid dates produce error. |
Date Tokenization for Cutover Dates of the Proleptic Gregorian Calendar
The data systems, such as, Oracle or Java-based systems, do not accept the cutover dates of the Proleptic Gregorian Calendar. The cutover dates of the Proleptic Gregorian Calendar fall in the interval 1582-10-05 to 1582-10-14. These dates are converted to 1582-10-15. When using Oracle, conversion occurs by adding ten days to the source date. Due to this conversion, data loss occurs as the system is not capable to return the actual date value after the de-tokenization.
The following points are applicable for the tokenization and de-tokenization of the cutover dates of the Proleptic Gregorian Calendar:
- The tokenization of the date values in the cutover date range of the Proleptic Gregorian Calendar results in an ‘Invalid Input’ error.
- During tokenization, an internal validation is performed to check whether the value is tokenized to the cutover date. If it is a cutover date, then the Year part (1582) of the tokenized value is converted to 3338 and then returned. During de-tokenization, an internal check is performed to validate whether the Year is 3338. If the Year is 3338, then it is internally converted to 1582.
Note:
The tokenization accepts the date range 0600-01-01 to 3337-11-27 excluding the cutover date range.
The de-tokenization accepts the date ranges 0600-01-01 to 3337-11-27 and 3338-10-05 to 3338-10-14.
Consider a scenario where you are migrating the protected data from Protector 1 to Protector 2. The Protector 1 includes the Date tokenizer update to process the cutover dates of the Proleptic Gregorian Calendar as input. The Protector 2 does not include this update. In such a scenario, an “Invalid Date Format” error occurs in Protector 2, when you try to unprotect the protected data as it fails to accept the input year 3338. The following steps must be performed to mitigate this issue:
- Unprotect the protected data from Protector 1.
- Migrate the unprotected data to Protector 2.
- Protect the data from Protector 2.
Date Tokenization Properties for different protectors
Application Protector
The following table shows supported input data types for Application protectors with the Date token.
Table: Supported input data types for Application protectors with Date token
| Application Protectors*2 | AP Java*1 | AP Python |
|---|---|---|
| Supported input data types | DATE STRING CHAR[] BYTE[] | DATE BYTES STRING |
*1 - The API accepts and returns data in BYTE[] format. The customer application needs to convert the input into byte arrays before calling the API, and similarly, convert the output from byte arrays after receiving the response from the API.
*2 - The Protegrity Application Protectors only support bytes converted from the string data type. If int, short, or long format data is directly converted to bytes and passed as input to the Application Protector APIs that support byte as input and provide byte as output, then data corruption might occur.
For more information about Application protectors, refer to Application Protector.
Big Data Protector
Protegrity supports MapReduce, Hive, Pig, HBase, Spark, and Impala, which utilizes Hadoop Distributed File System (HDFS) or Ozone as the data storage layer. The data is protected from internal and external threats, and users and business processes can continue to utilize the secured data. Protegrity protects data inside the files using tokenization and strong encryption protection methods.
The following table shows supported input data types for Big Data protectors with the Date token.
Table: Supported input data types for Big Data protectors with Date token
| Big Data Protectors | MapReduce*2 | Hive | Pig | HBase*2 | Impala | Spark*2 | Spark SQL | Trino |
|---|---|---|---|---|---|---|---|---|
| Supported input data types*1 | BYTE[] | STRING DATE*3 | CHARARRAY | BYTE[] | STRING DATE*3 | BYTE[] STRING | STRING DATE*3 | DATE*3 |
*1 – If the input and output types of the API are BYTE [], the customer application should convert the input to a byte array. Then, call the API and convert the output from the byte array.
*2 – The Protegrity MapReduce protector, HBase coprocessor, and Spark protector only support bytes converted from the string data type. Data types that are not bytes converted from the string data type might cause data corruption to occur when:
- Any other data type is directly converted to bytes and passed as input to the MapReduce or Spark API that supports byte as input and provides byte as output.
- Any other data type is directly converted to bytes and inserted in an HBase table. Where the HBase table is configured with the Protegrity HBase coprocessor.
*3 – In the Big Data Protector, the date format supported for Hive, Impala, Spark SQL, and Trino is YYYY-MM-DD only.
Date input values are not fully validated to ensure they represent valid dates. For instance, entering a day value greater than 31 or a month value greater than 12 will result in an error. However, the date 2011-02-30 does not cause an error but is converted to 2011-03-02, which is not the intended date.
For more information about Big Data protectors, refer to Big Data Protector.
Data Warehouse Protector
The Protegrity Data Warehouse Protector is an advanced security solution designed to protect sensitive data at the column level. This enables you to secure your data, while still permitting access to authorized users. Additionally, the Data Warehouse Protector integrates seamlessly with existing database systems using the User-Defined Functions for an enhanced security. Protegrity protects data inside the data warehouses using various tokenization and encryption methods.
The following table shows the supported input data types for the Teradata protector with the Date token.
Table: Supported input data types for Data Warehouse protectors with Date token
| Data Warehouse Protectors | Teradata |
|---|---|
| Supported input data types | VARCHAR LATIN |
For more information about Data Warehouse protectors, refer to Data Warehouse Protector.
Database Protectors
The following table shows supported input data types for Database protectors with the Date token.
Table: Supported input data types for Database protectors with Date token
| Protector | Oracle | MSSQL |
|---|---|---|
| Supported Input Data Types | DATE VARCHAR2 CHAR | VARCHAR CHAR |
For more information about Database protectors, refer to Database Protectors
Feedback
Was this page helpful?