Bug #6852
Problem with datetime-tz literal string conversion.
Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
10/18/2022
Due date:
% Done:
0%
billable:
No
vendor_id:
GCD
case_num:
Related issues
History
#1 Updated by Igor Skornyakov over 1 year ago
The field definition
FIELD fdatetime-tz1 as datetime-tz initial "10/17/2022 13:47:48.426+03:00" label "datetime-tz1"
is converted to
@Property(id = 14, name = "fdatetimeTz1", column = "fdatetime_tz1", legacy = "fdatetime-tz1", format = "99/99/9999 HH:MM:SS.SSS+HH:MM", initial = "10/17/2022", label = "datetime-tz1", order = 130) public datetimetz getFdatetimeTz1();
As we can see the time part is lost.
In the .parser
file I see:
define field [DEFINE_FIELD]:17179869551 @0:0 fdatetime-tz1 [SYMBOL]:17179869552 @17:11 as [KW_AS]:17179869554 @17:25 datetime-tz [KW_DATE_TZ]:17179869556 @17:28 initial [KW_INIT]:17179869558 @17:40 10/17/2022 [DATE_LITERAL]:17179869560 @17:48 label [KW_LABEL]:17179869562 @17:80 "datetime-tz1" [STRING]:17179869564 @17:86
Here, we see
DATE_LITERAL
instead of DATETIME_TZ_LITERAL
.
According to Greg this can be caused by a bug in initializer_constant
in progress.g
, more specifically at a relex()
step.
As far as I understand relex()
cannot properly and reliably detect the literal type since it does not consider vtype
at all. For example 4GL accepts "10/17/2022 13:47:48.426" as INITIAL value for datetime-tz
with session timezone but how relex()
can decide if it is DATETIME_TZ_LITERAL
or DATETIME_LITERAL
? Right now it treats it as DATE_LITERAL
.
#2 Updated by Igor Skornyakov over 1 year ago
- Related to Feature #6453: temp-table features added