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.
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
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.
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
Flag this post as spam/abuse.
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.
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
Flag this post as spam/abuse.
Flag this post as spam/abuse.
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
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
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
?
I get this ...
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?
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 :)
Forget it, I get it now. Ignore this last part. Just brain fade.
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
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
Flag this post as spam/abuse.