I have the same problem and I think that the severity is major, some people in our organisation miss their appointmnt due to this bug !
Sogo need to respect rfc2445 :

FORM 0000001: DATE WITH LOCAL TIME

The date with local time form is simply a date-time value that does
not contain the UTC designator nor does it reference a time zone. For
example, the following represents Janurary 18, 1998, at 11 PM:

 DTSTART:19980118T230000

Date-time values of this type are said to be "floating" and are not
bound to any time zone in particular. They are used to represent the
same hour, minute, and second value regardless of which time zone is
currently being observed.

I agreed with pbra, it's really a major issue, since it may confuse users/managers/directors.
But I think it is somewhat wider than mentioned earlier.
If it's required to file a new report about all next - please, let me know.
Here are my thoughts/tests/examples...

I see 13 common cases about formatting ICS and time/timezones.
In my opinion, SOGo violates RFC with 1,3 and also should be fixed with 4,6,8.
There is two main problems with SOGo:

• it doesn't treat the first case as local time
• it doesn't use it's own VTIMEZONE definitions, if none (or wrong) specified within the event.
  Despite I haven't met 3,9,10,12,13 cases in real life, they will help to form the right algorithm (which is at the end of the message).

These cases are:

1. DTSTART/DTEND without TZID. According to RFC2445, it should be displayed using local time (floating). Lightning/DAVdroid/iCal/iOS uses local time. SOGo uses UTC.

2. DTSTART/DTEND ending with "Z". Should be displayed using UTC+local_timezone_offset despite any VTIMEZONE definitions are given. Lightning/DAVdroid/iCal/iOS/SOGo uses UTC.

3. DSTART/DTEND ending with "Z" and TZID. Should be displayed using UTC+local_timezone_offset despite any TZID/VTIMEZONE definitions are given. Lightning/DAVdroid/iCal do so. iOS/SOGo uses event's VTIMEZONE definition.

4. DTSTART/DTEND with TZID, without VTIMEZONE definition. Lightning/DAVdroid/iCal/iOS uses it's own VTIMEZONE definitions. SOGo uses UTC.

5. DTSTART/DTEND with TZID and VTIMEZONE definition the same as client's VTIMEZONE definition. Lightning/DAVdroid/iCal/iOS/SOGo uses VTIMEZONE definition.

6. DTSTART/DTEND with TZID and VTIMEZONE that differs from client's VTIMEZONE definition. Lightning/iOS uses client's VTIMEZONE definition. DAVdroid/iCal/SOGo uses event's VTIMEZONE definition.

7. DTSTART/DTEND with TZID and VTIMEZONE that is unknown to client. Lightning/DAVdroid/iCal/iOS/SOGo uses event's VTIMEZONE definition.

8. DTSTART/DTEND with TZID, without VTIMEZONE and VTIMEZONE is also unknown to client. Lightning/DAVdroid/iCal/iOS uses local time (floating). SOGo uses UTC.

9. DTSTART/DTEND without TZID and VTIMEZONE, with VALUE=DATE and date-time format is yyyymmddThhmmss. Lightning/iCal/SOGo ignores VALUE, the time is as in 1. DAVdroid treats as all-day event.

10. DTSTART/DTEND without TZID and VTIMEZONE, with VALUE=DATE-TIME and date-time format is yyyymmdd. Lightning/iCal/SOGo ignores VALUE and shows as all-day. DAVdroid shows as all-day, but the time is also set (to 00:00:00).

11. DTSTART/DTEND without TZID and VTIMEZONE, with VALUE=DATE. Lightning/DAVdroid/iCal/iOS/SOGo uses all-day event.

12. DTSTART/DTEND without TZID and VTIMEZONE, DTSTART with VALUE=DATE-TIME, DTEND with VALUE=DATE. Lightning/DAVdroid/iCal/iOS uses DTSTART as local time, SOGo uses UTC (as in 1). Lightning/iCal calculates DTEND as 00:00:00, DAVdroid as 00:00:00+local_timezone_offset, iOS??, SOGo as 00:00:00(UTC)+local_offset.

13. DTSTART/DTEND without TZID and VTIMEZONE, DTSTART with VALUE=DATE, DTEND with VALUE=DATE-TIME. Lightning/DAVdroid. iCal/iOS/SOGo displays as all-day+1day event.

For better understanding I've created test events for every case. You can upload them to your CalDAV server using curl:
curl --insecure --basic --request PUT --header \
"Content-Type: text/calendar; charset=utf-8" \
-u USR:PASS -T FILENAME \
https://host/path/to/calendar

Attached test events (T01.ics, ... , T13.ics) start at 20151103T120000 (with various Z/TZID/VTIMEZONE/VALUE modifications).

Let's view them with SOGo 2.3.2:
If client's timezone is Europe/Moscow (UTC+03). We get:

• 1,2,4,8,9 starts at 15:00 (UTC + 3)
• 3,5 starts at 12:00 (event's VTIMEZONE)
• 6,7 starts at 11:00 (event's VTIMEZONE)
• 10,11 is all-day event
• 12 starts at 15:00, ends at 03:00 (UTC + 3)
• 13 is 2-days-long all-day event
  If client's timezone is Asia/Shanghai (UTC+08). We get:
• 1,2,4,8,9 starts at 20:00 (UTC + 8)
• 3,5 starts at 17:00 (event's VTIMEZONE)
• 6,7 starts at 16:00 (event's VTIMEZONE)
• 10,11 is all-day event
• 12 starts at 20:00, ends at 08:00 (UTC + 8)
• 13 is 2-days-long all-day event

Since Lightning uses the most correct logic (at least as I think), let's view events with Lightning 4.3.0.1 .
If client's timezone is Europe/Moscow (UTC+03). We get:

• 1,4,5,6,8,9 starts at 12:00 (1,8,9 - localtime, 4,5,6 - client's VTIMEZONE)
• 2,3 starts at 15:00 (UTC + 3).
• 7 starts at 11:00 (event's VTIMEZONE)
• 10,11,13 is all-day event
• 12 starts at 12:00, ends at 00:00
  If client's timezone is Asia/Shanghai (UTC+08). We get:
• 1,8,9 starts at 12:00 (localtime)
• 2,3 starts at 20:00 (UTC + 8).
• 4,5,6 starts at 17:00 (client's VTIMEZONE)
• 7 starts at 16:00 (event's VTIMEZONE)
• 10,11,13 is all-day event
• 12 starts at 12:00, ends at 00:00

You could test these events with any client you like, there will be different results with different clients...

I'm not a developer, but this generic code could be used to implement Lightning logic:

Variables:

DTSTR # DTSTART/DTEND/other string
DT # DTSTART/DTEND/other date-time without "Z" and "TZID" and "VALUE"
Z # true if DATE used with "Z" in the end (UTC)
TZID # TZID used with DT

all offsets are calculated for the given date-time, including daylight/standart handling

and time offset can also change the date

ETZO # event's VTIMEZONE TZID offset from UTC
CTZO # client's VTIMEZONE TZID offset from UTC
LTZO # local time offset from UTC
RDT # resulting date-time

let's call next code "f_datetime" function,

which input is any DTSTR-formatted string

and output is resulting date-time for current client's timezone (RDT).

This is the detailed "hard" logic (next you'll see the optimized logic):

DTSTR is given with "Z"

if Z then

despite any TZID or VTIMEZONE given (the time can not be "UTC" add "with offset" simultaneously),

use UTC + local time offset

RDT=DT+LTZO

No "Z"

else
if TZID is empty then

according to RFC, use localtime (floating)

RDT=DT

else

if event has no VTIMEZONE data about TZID offset

# (it could have data about another VTIMEZONE-TZID, but we don't care)...
if ETZO is empty then
  # ... and client has no VTIMEZONE data about TZID (including TZ aliases)
  if CTZO is empty then
    # we have no TZID offset data at all, use local time (floating)
    RDT=DT
  # ... but client has VTIMEZONE data about TZID offset
  else
    # use client's TZID offset and local time offset from UTC
    RDT=DT+LTZO-CTZO
  fi
# if event has VTIMEZONE data about TZID offset...
else
  # ... and client has no data about TZID offset (including TZ aliases)
  if CTZO is empty then
    # use event's TZID offset and local time offset from UTC
    RDT=DT+LTZO-ETZO
  else
    # ... and client has the same VTIMEZONE data about TZID offset as event has
    if CTZO = ETZO then
      # use event's or client's TZID offset and local time offset from UTC
      RDT=DT+LTZO-CTZO
    # ... and client's TZID offset data differs from event's TZID data.
    else
      # this is the moot point:
      #  * from one side, ORGANIZER should know the correct time of event.
      #    If the calculated time he gets using his own client is correct, all is ok, isn't it?
      #  * from another side, ORGANIZER's client could have wrong (old) timezone data and/or current time.
      #    This may lead client to display correct time with both wrong TZ and wrong current time settings.
      #    So, if this event is shared with someone else (which has correct TZ data and
      #    correct current time settings), his client's time will differ from ORGANIZER's time.
      #    This rule also works in reverse direction - when ORGANIZER has the right settings,
      #    but ATTENDEE doesn't.
      # We should choose, which TZID offset to use. Both choices may lead to a difference in time between clients.
      # But broken client is free to set another timezone (there are many),
      # which will give the same correct offset/time used by another participant - this is an easy workaround.
      # So, I take the side of fresh-updated clients and correctly configured time/timezone.
      # Like lightning does. Client's TZID offset overrides event's TZID offset.
      RDT=DT+LTZO-CTZO
    endif
  endif
endif

endif
endif

Here is the optimized variant:

if Z then
RDT=DT+LTZO
else
if TZID is empty then
RDT=DT
else
if CTZO is empty then
if ETZO is empty then
RDT=DT
else
RDT=DT+LTZO-ETZO
endif
else
RDT=DT+LTZO-CTZO
endif
endif
endif
return RDT

About 9,10, they are anyway inconsistent. DAVdroid treats them closer to RFC, but others get more "human" info from such events.
If we'd like to treat cases 9,10 as DAVdroid, we should skip all code above if VALUE=DATE, and set both DTSTART/DTEND to 00:00:00 if VALUE=DATE-TIME and the given format is yyyymmhh.

About 11,12,13 - here is the Lightning-like algorithm:

Variables:

DTS # true if current DTSTR is DTSTART
DTE # true if current DTSTR is DTEND
D # true if current DTSTR is yyyymmdd formatted
ADE # current event is all-day event flag, defaults to false
RD # resulting date, yyyymmdd
RT # resulting time, hhmmss

f_datetime(DT) functions is described above

f_date(DT) is a function which input is any DTSTR

and output is the resulting date (yyyymmdd formatted).

f_d(RDT) is a function which input is RDT-formatted string, output - yyyymmdd formatted date

f_t(RDT) is a function which input is RDT-formatted string, output - hhmmss formatted time

The next function input is DTSTR,DTS,DTE

and output ADE,RD,RT.

if DTS then
if not D then
RD=f_d(f_datetime(DTSTR))
RT=f_t(f_datetime(DTSTR))
else
ADE=true
RD=f_date(DTSTR)
RT=000000
fi
fi
if DTE then
if not ADE and not D then
RD=f_d(f_datetime(DTSTR))
RT=f_t(f_datetime(DTSTR))
else
RD=f_date(DTSTR)
RT=000000
fi
fi
return ADE,RD,RT

similar if-else could be made about DUE,EXDATE,RDATE,TRIGGER

As I can see the required changes should be made near "SOPE/NGCards/iCalDateTime.m"

Hope this will help to fix this bug (and may be others). I'm ready to provide more info, tests, etc.

Thanks for attention!

Are there any news regarding this issue, plans to improve the situation?

I've had a look today and this is fairly nasty because in all SOPE/NGCards/* classes, we don't have access to the user's timezone.