Profile generic row dates are affected by local PCs DST settings what may result in incorrect dates

Update on this:

Simply replacing local DateTime (dt.Value.LocalDateTime) with the meters DateTimeOffset (dt.Value) will fix the issue and let us have the original date and correctly convert it to UTC or local time if required.

Meter | UTC | Local
10/25/2020 12:00:00 AM +02:00 | 2020-10-24 22:00:00 | 2020-10-25 01:00:00 / "+3"
10/25/2020 1:00:00 AM +02:00 | 2020-10-24 23:00:00 | 2020-10-25 02:00:00 / "+3"
10/25/2020 2:00:00 AM +02:00 | 2020-10-25 00:00:00 | 2020-10-25 03:00:00 / "+3"
10/25/2020 3:00:00 AM +02:00 | 2020-10-25 01:00:00 | 2020-10-25 03:00:00 / "+2"
10/25/2020 4:00:00 AM +02:00 | 2020-10-25 02:00:00 | 2020-10-25 04:00:00 / "+2"

Yes, only the first row contains the date (meter is ISKRA MT880)

Row [0] column [0]: System.Byte[]
Row [1] column [0]: null
Row [2] column [0]: null
Row [3] column [0]: null
Row [4] column [0]: null

It is not causing problems as you handle such cases by increasing previous date by profile capture period.

But, for some reason, you don't keep the last date in meter timezone (only first date), but convert it to local time (lastDate = dt.Value.LocalDateTime;)

10/23/2020 11:00:00 PM +02:00 //meter timezone, correct
10/24/2020 1:00:00 AM +03:00 // converted to local

This makes it dependent on local PCs DST and when DST change happens local time is shifted back/forward and correlation with the original time is lost.

It would be more explicit to have all dates in meter timezone and convert them to UTC/local later when you need to display it to the user.

Hello,

Thank you for a quick update, but it seems that dates are still inconsistent as original timezone is lost.

1. https://github.com/Gurux/Gurux.DLMS.Net/blob/master/Development/Objects…
lastDate = dt.Value.DateTime;
you keep the date, but timezone/offset information is lost here

2. https://github.com/Gurux/Gurux.DLMS.Net/blob/master/Development/Objects…
GXDateTime(DateTime value) will call GXDateTime(DateTime value, TimeZoneInfo timeZone) with no timezone info and will calculate offset from local time TimeZoneInfo.Local.GetUtcOffset(value)

This will produce the following results:
10/24/2020 4:30:00 AM +02:00 //1st record
10/24/2020 4:45:00 AM +03:00 //2nd record has meter time, but uses local timezone

And DST:
10/25/2020 2:30:00 AM +03:00 //UTC 11:30:00 PM
10/25/2020 2:45:00 AM +03:00 //UTC 11:45:00 PM
10/25/2020 3:00:00 AM +02:00 //UTC 1:00:00 AM <-wrong
10/25/2020 3:15:00 AM +02:00 //UTC 1:15:00 AM

This can be solved by using the same DateTimeOffset to keep the last date and preserve the original meters timezone:

GXDateTime dt = (GXDateTime)row[pos];
lastDate = dt.Value;

and dates can be correctly converted to UTC/Local timezone

10/25/2020 1:45:00 AM +02:00 | UTC 2020-10-24 23:45:00
10/25/2020 2:00:00 AM +02:00 | UTC 2020-10-25 00:00:00
10/25/2020 2:15:00 AM +02:00 | UTC 2020-10-25 00:15:00
10/25/2020 2:30:00 AM +02:00 | UTC 2020-10-25 00:30:00
10/25/2020 2:45:00 AM +02:00 | UTC 2020-10-25 00:45:00
10/25/2020 3:00:00 AM +02:00 | UTC 2020-10-25 01:00:00
10/25/2020 3:15:00 AM +02:00 | UTC 2020-10-25 01:15:00

Hello,

Yes, if you keep the date in DateTimeOffset and use dt.Value as lastValue the correct timezone offset will be preserved.

In fact, it all depends on how you initialize GXDateTime - passing DateTimeOffset will use the date and offset from it, but passing DateTime with no offset information will use local PCs default timezone and is dependent on PCs DST settings

10/23/2020 11:00:00 PM +02:00 //meter timezone, correct
10/24/2020 1:00:00 AM +03:00 //GXDateTime from DateTime with no offset, uses local PC timezone