You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please answer the following questions before submitting your issue. Thanks!
Describe what you find is inappropriate or missing in the existing docs.
There is no mention about DATE/TIME and TIMESTAMP literal, which can be written as DATE'2024-11-28', TIME'14:22:39' and TIMESTAMP'2024-11-28 14:22:11' in the literal values section.
Describe your suggestion or addition.
Implementation wise it differs slightly if only using a string, and let the parser/function/data type do implicit conversion from string to date/time/timestamp. Normally the result is the same, but there are stricter checks for DATE/TIME and TIMESTAMP explicit literals.
Also note that TIMESTAMP literal is first interpreted as in current @@time_zone unless explicitly setting time_zone offset (see tidb#57845) and then set as DATETIME datatype, which can be good to know when working with implicit data type conversion during comparison between different literals and column types.
Also the explicit time zone offset [+-]HH:MM or TiDB extension 'Z' as in 2024-11-28 14:22:31+08:00 or 2024-11-28 14:22:31Z is not documented (time zone offset waiting for PR for explicit TIMESTAMP literal, and 'Z' is only supported by implicit timestamp literal).
Change Request
Please answer the following questions before submitting your issue. Thanks!
Describe what you find is inappropriate or missing in the existing docs.
There is no mention about DATE/TIME and TIMESTAMP literal, which can be written as
DATE'2024-11-28'
,TIME'14:22:39'
andTIMESTAMP'2024-11-28 14:22:11'
in the literal values section.Describe your suggestion or addition.
Implementation wise it differs slightly if only using a string, and let the parser/function/data type do implicit conversion from string to date/time/timestamp. Normally the result is the same, but there are stricter checks for DATE/TIME and TIMESTAMP explicit literals.
Also note that TIMESTAMP literal is first interpreted as in current
@@time_zone
unless explicitly setting time_zone offset (see tidb#57845) and then set as DATETIME datatype, which can be good to know when working with implicit data type conversion during comparison between different literals and column types.Provide some reference materials (such as documents and websites) if you could.
https://docs.pingcap.com/tidb/stable/literal-values
The text was updated successfully, but these errors were encountered: