Regression on GXDateTime deviation field

Forum Rules

Before commenting read Forum rules

Don't comment the topic if you have a new question.

You can create a new topic selecting correct category from Gurux Forum and then create a new topic selecting "New Topic" from the top left.

By Nico , 8 June, 2017
Forums
Gurux DLMS for Java

Hello,

Recently upgrading from Gurux 1.4.5 to 2.1.1, I noticed an issue concerning the setting/getting of the deviation field when creating a GXDateTime object.

This simple unit test below:
@Test
public void testGXDateTime() {
int deviationOne = 60;
GXDateTime dt = new GXDateTime(2017,02,04,12,00,0,0,deviationOne);
int deviationTwo = dt.getDeviation();
assertEquals(deviationOne, deviationTwo);
}

Gives:
java.lang.AssertionError:
Expected :60
Actual :-60

Could you please confirm that this is an issue?
And would you have any idea on how to fix this ?

Thanks

nico

Kurumi

9 years ago

Hi,

First. Use version 2.1.4. It's the latest.

Standard says that deviation is in minutes of local time to UTC (Page 46 in Blue book). So, if your timezone is 60, deviation is -60. In my mind this is not a good idea and I know that there are lots of meters where deviation = Time Zone. (60=60). But we can't effect to it.

getDeviation returns current time zone to UTC time.
devitation in constructor is actual time zone. There is a historical reason and we can't change this.

I'll have add work list that we'll rename constructor deviation to timeZone.

BR,

Mikko

Hi Mikko,

Thanks for your very prompt message.
I am now using version 2.1.4 indeed.

it is true that the name is misleading but your explanation is very clear and helpful - maybe a comment in the source code would prevent confusion ?

Thanks again,

Nico

Dmitry R.

4 years 8 months ago

Hi,

Can we be sure enough to consider the deviation the minus-operand to the local time istead of timezone as itself?
Suppose The Blue Book says it ambiguously:
- ... in minutes of local time to UTC (GMT)...
I give it rather plus then minus. Also the diagram in The Blue Book concerning the DST shift handling shows the positive shift at the start of DST (summer) period and the negative one at the end, so don't you think it means that deviation for the +timezones should be positive (i.e. deviation=timezone)?
May be there are any clarifications from the DLMS Association experts, aren't there?