ignore time part of GXDateTime

I also looked at GxDate, but in converting to hex it translated into 5 bytes, that I think it's not correct for reading load profile.
case GXDate _:
buff.SetUInt8((byte) 5);
GXCommon.SetDate(settings, buff, value);
return;
case DateTime _:
buff.SetUInt8((byte) 12);
GXCommon.SetDateTime(settings, buff, value);
return;

if I use skip property of GxDateTime,every thing work ok except Deviation that replaces with 80 00
instead of FF FF,

if ((gxDateTime.Skip & DateTimeSkips.Deviation) == DateTimeSkips.None)
{
short totalMinutes = (short) gxDateTime.Value.Offset.TotalMinutes;
if (settings != null && settings.UseUtc2NormalTime)
buff.SetInt16(totalMinutes);
else
buff.SetInt16(-totalMinutes);
}
else
buff.SetUInt16((ushort) 32768);

can we do anything about this ?

as you know sl7000 does not implement dlms correctly. we have a lot of sl7000 meters. about 99 percent of them, does not have a problem. but only for 1% of them, I get access violated error on reading it's second load profile. I analyzed aimsPro packets and my packets, there was two differences in get request that I changed them after I get packet from your library.
but I stile get the same access violated error.
the differences was on 020412000809060000010000FF0F02120000090C that aims pro send simply
00090C for clock obis in get packet and time part that I already said above.
I should say that after changing packet contents, I checked them with translator and all of them was correct.
do you have any other idea ?

we don't have access to new firmware. I also checked the version on meters and all meters are the same one.
also I changed 32768 to 0xFFFF and newly created packet is the same as aimsPro Packet.
but i checked snrm packet that we send and I see that :
<MaxInfoTX Value="117" />
<MaxInfoRX Value="114" />
I changed this values to 128. but then it send this values again. I don't hnow where this changes ? do you have any idea?

yes I changed them, but again it uses this values. if I don't set UseFrameSize , then everything is Ok.
but If I use UseFrameSize =true, then this values(117,114) apply instead of 128.