Project

General

Profile

Bug #6852

Problem with datetime-tz literal string conversion.

Added by Igor Skornyakov almost 4 years ago. Updated almost 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
10/18/2022
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

Related issues

Related to Database - Feature #6453: temp-table features Closed

History

#1 Updated by Igor Skornyakov almost 4 years 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 almost 4 years ago

Also available in: Atom PDF