Calender entries only contain the hour - not the minute

[theseer]

I'm maintaining my calender on my personal caldav server and sync those to my Xperia 10 II phone. From there they seemingly get synced via amazfish to the GTS 2.

While the general date and hour is correct, the minute information somehow gets lost in transit and is always :00.

Is that expected behavior? ;)

[theseer]

I've been digging a bit around in the journal logs as well as the source code. Maybe that's not helpful at all, but I figured I write it here anyway ;)

When syncing up my "test 2" appointment entry, i found the following entries in the log:

2023-02-01 22:56:33.559 : "NBUID:1f97a1a6-ac72-42a9-8c73-ada0aea63a95:e87ba719baed54519d669fddd9c4f269a0bf2763" "test 2" QDateTime(2023-02-04 10:33:00.000 CET Qt::TimeSpec(TimeZone) Europe/Berlin)
2023-02-01 22:56:33.559 : QDateTime(2023-02-04 10:33:00.000 CET Qt::TimeSpec(TimeZone) Europe/Berlin) "test 2"
2023-02-01 22:56:33.559 : UTC offset it  0
2023-02-01 22:56:33.559 : converted date QDateTime(2023-02-04 10:33:00.000 CET Qt::TimeSpec(TimeZone) Europe/Berlin) to "\xE7\x07\x02\x04\n!\x00\x00"
2023-02-01 22:56:33.559 : Writing chunked:  "\x0B\x0F\t\x00\x00\x00\xE7\x07\x02\x04\n\x00\x00test 2\x00"

The code in question is typeconversion.cpp#L28.

Its output makes sense (after some confusion due to the ascii chars in the byte dump):

• \xE7\x07 is the year (2023)
• \x02 the month (2)
• \x04 is the day (4)
• \n is the hour (10, printed as ascii char)
• ! is the minute (33, printed as ascii char)
• \x00 is just appended
• \x00 is appended again, given the utcOffset is statically 0 and thus the calculation always returns 0.

In the actual bytes being sent though, according to the log, the ! char/byte vanished. Which would explain the missing minute information.

Now I only need to find the place where it's actually being sent...

[theseer]

The only place I found in the code base that deals with events and calling typeConversion::dateTimeToBytes is gtsdevice.cpp#L205:

cmd += TypeConversion::dateTimeToBytes(dt, 0).left(5);

I'm not sure why this is cut off - apparently the additional trailing \x00 aren't needed here -, but given that QByteArray::left expects a length and not an end position, it should be 6 not 5. (2 bytes for year, 1 byte for month, 1 byte for day, 1 byte for hour, 1 byte for minute is 6 bytes not 5.)

[piggz]

Thanks for this, ill just quickly check what gadgetbridge does, but you could certainly be right

[piggz]

Yeah, looks like you are correct https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/master/app/src/main/java/nodomain/freeyourgadget/gadgetbridge/service/btle/BLETypeConversions.java#L95

[theseer]

Consider creating a new release? ;-)

[FingusDE]

I spotted that long time ago but think that was a feature (to remind before the event)