Changes have been made in Git (FRAMEWORK_5_1):

commit f3ecf11715fae2216a6a4b8497d6a08d2f6b3b0c
Author: Jan Schneider <jan@horde.org>
Date:   Wed Apr 16 15:01:50 2014 +0200

     [jan] Fix history not always returning the last modification time 
of an event (Bug #13113).

  kronolith/docs/CHANGES |    2 ++
  kronolith/package.xml  |    2 ++
  2 files changed, 4 insertions(+), 0 deletions(-)

http://github.com/horde/horde/commit/f3ecf11715fae2216a6a4b8497d6a08d2f6b3b0c

Changes have been made in Git (FRAMEWORK_5_1):

commit f0492f96adf4fdd2594409417bcba013d16eeb66
Author: Jan Schneider <jan@horde.org>
Date:   Wed Apr 16 14:57:37 2014 +0200

     Don't pile up modifications in history log.

     The changes introduced for request #10249 did accumulate all event
     modifications in the history log, which eventually lead to bug 
#13113. Until
     Horde_History doesn't scale better for large user numbers, we 
should not log
     even more stuff. Especially if we don't even use this information 
anywhere.

  kronolith/lib/Driver/Sql.php |    4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

http://github.com/horde/horde/commit/f0492f96adf4fdd2594409417bcba013d16eeb66

Changes have been made in Git (FRAMEWORK_5_1):

commit 862b4377e6474a244f2523354d598089266f42d9
Author: Jan Schneider <jan@horde.org>
Date:   Wed Apr 16 14:52:37 2014 +0200

     Only return the latest modification (Bug #13113).

  kronolith/lib/Event.php |    4 ++++
  1 files changed, 4 insertions(+), 0 deletions(-)

http://github.com/horde/horde/commit/862b4377e6474a244f2523354d598089266f42d9

Changes have been made in Git (master):

commit 122e6dfad7a65cb9c9ef59a3eef7e4212e317f9e
Author: Jan Schneider <jan@horde.org>
Date:   Wed Apr 16 14:57:37 2014 +0200

     Don't pile up modifications in history log.

     The changes introduced for request #10249 did accumulate all event
     modifications in the history log, which eventually lead to bug 
#13113. Until
     Horde_History doesn't scale better for large user numbers, we 
should not log
     even more stuff. Especially if we don't even use this information 
anywhere.

  kronolith/lib/Driver/Sql.php |    4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

http://github.com/horde/horde/commit/122e6dfad7a65cb9c9ef59a3eef7e4212e317f9e

Changes have been made in Git (master):

commit f9fca18d62f3489f06ff4029d50dd0f2a2a2826d
Author: Jan Schneider <jan@horde.org>
Date:   Wed Apr 16 14:52:37 2014 +0200

     Only return the latest modification (Bug #13113).

  kronolith/lib/Event.php |    4 ++++
  1 files changed, 4 insertions(+), 0 deletions(-)

http://github.com/horde/horde/commit/f9fca18d62f3489f06ff4029d50dd0f2a2a2826d

I'm using:

kronolith                 4.1.5   stable
horde                     5.1.6   stable
Horde_Dav                 1.0.4   stable

PEAR does not list any outstanding upgrades.

If I delete the user data of user "user", login, create a new event 
and add the standard calendar to KDE Akonadi via CalDAV, that event is 
sync'ed to KDE. Then I change the start time in Kronolith, the change 
is sync'ed to KDE again. Then I change one or more times again in the 
GUI only, those changes are not sync'ed to KDE.

If I change the event in KDE's Korganiser, the change is sync'ed to 
Kronolith, then I can change the event in the GUI one time again in 
order to sync it back to KDE.

The horde_histories table contains entries of change of the GUI, e.g.:

      67138 | 
kronolith:lRKXIP8i9MAv6KDdx3OFew1:20140414091444.DpToeX4M_xh0ohIpZIDZpQ2@... | 
modify  | ... | a:2:{s:3:"new";a:10:{s ...

I sniffed the CalDAV connection, in the 207 Multi-Status reponses of 
the REPORT requests, I get:

<d:response>
   
<d:href>/horde/rpc.php/calendars/user/calendar:lRKXIP8i9MAv6KDdx3OFew1/HOu4xpua-p9SaC_JViE0Iw1.ics</d:href>
<d:propstat><d:prop><d:getetag>"abb796829cd0403ee6c3f0a25270ad30"</d:getetag>
<d:resourcetype/></d:prop>
<d:status>HTTP/1.1 200 OK</d:status></d:propstat></d:response>

The etag does not change beginning with the 2nd change of an event in 
Kronolith, no matter how often I change the event in Kronolith or try 
to re-sync the calendar from KDE. Because I understand section 
"Finding out if anything changed" of 
http://sabre.io/dav/building-a-caldav-client/ so, that the client may 
use the etag to find changes, the KDE does not request the event 
again, because the etag stays the same as the previous request.

=====

KDE Akonadi uses this REPORT request:

REPORT /horde/rpc.php/calendars/user/calendar:lRKXIP8i9MAv6KDdx3OFew1/ 
HTTP/1.1\r\n

<calendar-query xmlns="urn:ietf:params:xml:ns:caldav">
  <prop xmlns="DAV:">
   <getetag xmlns="DAV:"/>
   <resourcetype xmlns="DAV:"/>
  </prop>
  <filter xmlns="urn:ietf:params:xml:ns:caldav">
   <comp-filter xmlns="urn:ietf:params:xml:ns:caldav" name="VCALENDAR">
    <comp-filter xmlns="urn:ietf:params:xml:ns:caldav" name="VEVENT"/>
   </comp-filter>
  </filter>
</calendar-query>

====

In Kronolith_Event::loadHistory() the modified entries are in that order:
loadHistory()
loadHistory(modified)=1397465499 who=user
loadHistory(modified)=1397464675 who=user
loadHistory(modified)=1397460856 who=user
loadHistory(modified)=1397460722 who=user
loadHistory(modified)=1397459781 who=user
loadHistory(modified)=1397459749 who=user
loadHistory(modified)=1397459728 who=user

The last one wins, which is the one with the smallest / eldest 
timestamp. Because of this the etag remains unchanged and KDE does not 
queries the event data. Attached patch compares the timestamps of all 
items returned and evaluates the highest / youngest timestamp only. 
This change fixes my problem.