Inconsistency assigning date var to datetime-tz vs. using th

Posted by tbergman on 09-Apr-2014 09:53

Progress 11.3 Windows.

The following code illustrates the problem. It's likely sensitive to the time zone you're in when you run it. In our testing, in the Eastern time zone, the problem occurs when we are in a timezone that is 1 hour ahead of the timezone stored in the datetime-tz variable.

DEFINE VARIABLE vdateTZ AS DATETIME-TZ.
DEFINE VARIABLE vDate1 AS DATE.
DEFINE VARIABLE vDate2 AS DATE.
vDateTZ = datetime-tz(4,9,2014,0,0,0,0,-180).
vDate1 = vDateTZ.
vDate2 = date(vDateTZ).
MESSAGE now skip vDateTZ SKIP vDate1 SKIP vDate2 VIEW-AS ALERT-BOX.

The output I get is:
04/09/2014 10:45:39.494-04:00
04/09/2014 00:00:00.000-03:00
04/08/14
04/09/14

Note the different dates shown by vDate1 and vDate2.
 

 

All Replies

Posted by Brian K. Maher on 09-Apr-2014 10:01
Tom,
 
I think this is a bug.  Please open a support call for it.
 
Thanks, Brian
 
[collapse]
From: tbergman [mailto:bounce-tbergman@community.progress.com]
Sent: Wednesday, April 09, 2014 10:54 AM
To: TU.OE.Development@community.progress.com
Subject: Inconsistency assigning date var to datetime-tz vs. using the date function
 
Inconsistency assigning date var to datetime-tz vs. using the date function
Thread created by tbergman

Progress 11.3 Windows.

The following code illustrates the problem. It's likely sensitive to the time zone you're in when you run it. In our testing, in the Eastern time zone, the problem occurs when we are in a timezone that is 1 hour ahead of the timezone stored in the datetime-tz variable.

DEFINE VARIABLE vdateTZ AS DATETIME-TZ.
DEFINE VARIABLE vDate1 AS DATE.
DEFINE VARIABLE vDate2 AS DATE.
vDateTZ = datetime-tz(4,9,2014,0,0,0,0,-180).
vDate1 = vDateTZ.
vDate2 = date(vDateTZ).
MESSAGE now skip vDateTZ SKIP vDate1 SKIP vDate2 VIEW-AS ALERT-BOX.

The output I get is:
04/09/2014 10:45:39.494-04:00
04/09/2014 00:00:00.000-03:00
04/08/14
04/09/14

Note the different dates shown by vDate1 and vDate2.
 

 

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]
Posted by Robin Brown on 09-Apr-2014 12:08
Hi Tom,
 
As you have shown, there is a difference between taking a datetime-tz and assigning it to a date and taking the date part of a datetime-tz and assigning it to a date.  Per the documentation on the DATE(datetime-expression)  function:
 
If datetime-expression is a DATETIME-TZ, the DATE function returns the date
relative to the time zone of the DATETIME-TZ value. For example, a DATETIME-TZ
field, fdt, is created in London (time zone UTC+00:00) with a value of May 5, 2002 at
7:15:03.002 am. DATE (fdt) returns 05/05/2002, regardless of the session’s time zone.
 
For straight assignment between date and datetime-tz, we do take the session’s time zone into account.
 
So I would not consider this a bug.
 
Regards,
Robin
 
[collapse]
From: Brian K. Maher [mailto:bounce-maher@community.progress.com]
Sent: Wednesday, April 09, 2014 11:02 AM
To: TU.OE.Development@community.progress.com
Subject: RE: Inconsistency assigning date var to datetime-tz vs. using the date function
 
Reply by Brian K. Maher
Tom,
 
I think this is a bug.  Please open a support call for it.
 
Thanks, Brian
 
[collapse]
From: tbergman [mailto:bounce-tbergman@community.progress.com]
Sent: Wednesday, April 09, 2014 10:54 AM
To: TU.OE.Development@community.progress.com
Subject: Inconsistency assigning date var to datetime-tz vs. using the date function
 
Inconsistency assigning date var to datetime-tz vs. using the date function
Thread created by tbergman

Progress 11.3 Windows.

The following code illustrates the problem. It's likely sensitive to the time zone you're in when you run it. In our testing, in the Eastern time zone, the problem occurs when we are in a timezone that is 1 hour ahead of the timezone stored in the datetime-tz variable.

DEFINE VARIABLE vdateTZ AS DATETIME-TZ.
DEFINE VARIABLE vDate1 AS DATE.
DEFINE VARIABLE vDate2 AS DATE.
vDateTZ = datetime-tz(4,9,2014,0,0,0,0,-180).
vDate1 = vDateTZ.
vDate2 = date(vDateTZ).
MESSAGE now skip vDateTZ SKIP vDate1 SKIP vDate2 VIEW-AS ALERT-BOX.

The output I get is:
04/09/2014 10:45:39.494-04:00
04/09/2014 00:00:00.000-03:00
04/08/14
04/09/14

Note the different dates shown by vDate1 and vDate2.
 

 

Stop receiving emails on this subject.

Flag this post as spam/abuse.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse][/collapse]
Posted by tbergman on 11-Apr-2014 10:51

Hi Robin,

I had seen the documentation for the DATE function, I'm just concerned that there's no documentation about the implicit conversion done during direct assignment. Or at least none I've seen.

Other than this, all implicit conversions in Progress that I've seen behave in a manner consistent with their explicit conversions. Take for example:

MyInt = Int(MyDecimal) vs. MyInt = MyDecimal

or

MyInt64 = Int64(MyInteger) vs. MyInt64 = MyInteger.

Do I have to start worrying about subtle differences between these statements?

In this particular case, I would have preferred a compile time error to the behavior observed.

Tom

Posted by Robin Brown on 14-Apr-2014 15:30

Hi Tom,

The assignment behavior between DATE, DATETME, and DATETIME-TZ is documented in the ABL Reference under the Assignment (=) and ASSIGN statements.  It isn't easy to find based on the amount of notes under these statements.  I see your point, but since this is behavior that has been around since 10.0A, I don't see us changing it.

Regards,

Robin  

Posted by tbergman on 15-Apr-2014 10:23

Hi Robin,

I can understand not changing it.

While on the subject, I decided to try going from Datetime-tz to datetime and got a result I can't explain. Basically the same code.

When I run this, I get 11PM on April8 for vDate 1. Where, and in what timezone, is it 11PM and why would I get that result?

DEFINE VARIABLE vdateTZ AS DATETIME-TZ.

DEFINE VARIABLE vDate1 AS DATETIME.

DEFINE VARIABLE vDate2 AS DATETIME.

vDateTZ = datetime-tz(4,9,2014,0,0,0,0,-180).

vDate1 = vDateTZ.

/*vDate2 = datetime(vDateTZ).*/

MESSAGE NOW SKIP vDateTZ SKIP vDate1 SKIP vDate2

VIEW-AS ALERT-BOX.

The result is:

04/15/2014 11:22:24.161-04:00

04/09/2014 00:00:00.000-03:00

04/08/2014 23:00:00.000

?

Posted by jmls on 15-Apr-2014 10:30

I get this ...

Posted by Fernando Souza on 15-Apr-2014 10:36

Notice how the NOW function returned a datetime-tz with timezone as -04:00. That is your session's timezone setting. When you converted vDateTZ into a date, as Robin explained, we have to convert it to the session's timezone setting, hence it being one hour earlier, that is, represented in the -04:00 timezone. Does it make sense now?

Posted by tbergman on 15-Apr-2014 10:43

But it's not one hour earlier in eastern time, it's one hour later. At midnight Central time, it's 1AM eastern, not 11PM the day before.

I'm confused :)

Posted by tbergman on 15-Apr-2014 10:48

Forget it, I get it now. Ignore this last part. Just brain fade.

Posted by Robin Brown on 15-Apr-2014 10:52

Hi Tom,

Per the assignment rules, the datetime-tz is converted to the local date and time for the session's time zone  (-04:00), and the time zone is dropped.  At midnight on 04/09 in the -03:00 time zone, it is 11pm on 04/08 in the session's time zone.  This logic is the same as when you were assigning to a DATE, but the time was also dropped.

Robin

Posted by Robin Brown on 15-Apr-2014 10:58
Sorry for the duplicate post.  I hadn’t noticed Fernando’s reply.
 
Robin
 
[collapse]
From: Robin Brown [mailto:bounce-rbrown@community.progress.com]
Sent: Tuesday, April 15, 2014 11:53 AM
To: TU.OE.Development@community.progress.com
Subject: RE: Inconsistency assigning date var to datetime-tz vs. using the date function
 
Reply by Robin Brown

Hi Tom,

Per the assignment rules, the datetime-tz is converted to the local date and time for the session's time zone  (-04:00), and the time zone is dropped.  At midnight on 04/09 in the -03:00 time zone, it is 11pm on 04/08 in the session's time zone.  This logic is the same as when you were assigning to a DATE, but the time was also dropped.

Robin

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]
This thread is closed