Liferay 6.2 Calendar DST support?

[Diego Morales, módosítva 10 év-val korábban]

Is daylight savings time supported in the community edition v.6.2. When I try to configure the timezone for a user all I see are UTC Timezones.

Thank you-

[David H Nebinger, módosítva 10 év-val korábban]

Yes it is supported, but normally you'll pick your regular timezone (i.e. I am US Eastern), and DST is included automagically (assuming, of course, that your govt doesn't play around with the start/end of DST like they've done here in the US). In any case, DST support is in the JVM, and is not a function of Liferay itself.

[Diego Morales, módosítva 10 év-val korábban]

Ok, thank you

[Tobias Tiederle, módosítva 10 év-val korábban]

Hi,

I can see how that works for single events, but how about repeating events?

Let's say I live in Britain and want to fix a regular weekly meeting at 16:00 local time.
So from my perspective it should never change.
Someone joining me from the US in the EST/EDT would have to see very different times over the year:
- until 9 March it would be 11:00
US DST starts
- 9 March - 30 March it would be 12:00
UK DST starts
- 30 March -26 October it would be 11:00
US DST ends
- 26 October until 2 November it would 12:00
UK DST ends
- after 2 November it would be 11:00

Instead, what happens (and I tried this by setting the server time to different times and checking what the calendar shows for different people)
- until 9 March, all fine, because I created the event with no DST in effect
- From 9 March, still fine, US DST starts and the us guy sees the changed time at 12:00
- From 30 March until 26 October, my meeting suddenly starts at 17:00! That should not have happened!
The US time has of course not changed.
- 26 October until the end of the year, my meeting is back at 16:00 (phew) and the US time adjusts as expected.

So basically this calendar is not usable for repeated events fixed to local time spanning DST changes for that timezone.
Fail.

Regards,
Tobias Tiederle

[David H Nebinger, módosítva 10 év-val korábban]

A time for a meeting is still just a time. Remember, these are (normally) stored in GMT in the database, and effectively they are all longs w/ the number of secs since the epoch. That doesn't change at any part of the year.

When you are in a country that has DST, the clock automatically adjusts around the DST boundaries. Again it's the user's clock, not the date stored in the system or anything like that. The user's clock makes the switch and the DST is taken into account when converting the GMT time (secs from the epoch) into a local representation of the hour of the day.

You as a developer or administrator or event scheduler do not have to worry about how someone's clock is going to present the time to them. You just use the date and it is done.

That is assuming, of course, that you haven't changed the app server's timezone out of GMT (some admins do that because they feel it is not necessary to store their times in GMT when the environ is supposed to be local to them) and your users have their timezones set correctly (there's nothing that forces a user to adjust their Liferay timezone, it's buried in the display settings in their user profile and, unless you've noticed weird times and want to fix them, have no reason to go to that profile page) and you haven't done something in your code (i.e. you try to get fancy with your time handling code)...

[Jim Trott, módosítva 10 év-val korábban]

I have to agree with Tobias. I have tried many options to get daylight savings to work as expected. As far as i know, we have everything configured correctly in portal settings and server. I have tried multiple configurations of calendar portlet and My Display Settings. DST does not behave correctly. It is instructive to see that DST behaved correctly in the Liferay 6.1 calendar portlet.

Fail.

[David H Nebinger, módosítva 10 év-val korábban]

It's a fail if you use local time for the server.

Your app server should always execute using GMT, "-Duser.timezone=GMT" as a command line parameter.

Then you use the control panel to indicate the default timezone for users, and users use the display settings control panel to choose their own timezone.

In this way, when person A in england sets a recurring meeting for 4pm. This is stored in the database as the appropriate GMT time. User B in the US who puts the meeting on their calendar will see it change as they move in and out of DST.

Trust me, that's how the GMT stuff is supposed to work.

[Mika Koivisto, módosítva 10 év-val korábban]

Actually it should be UTC not GMT.

[David H Nebinger, módosítva 10 év-val korábban]

GMT works too, Mika, that's the value we're using onsite.

[Jim Trott, módosítva 10 év-val korábban]

Today, the US converted to DST in all states but Arizona. Looking at my calendar, the times for all events have adjusted to the new time. Thus,
Last week (before DST), the time for ALL of meetings in Repeating Event A showed as 15:00 WET and 07:00 PST.
Today, (after DST), ALL of the meetings in Repeating Event A (even those last week) show as 15:00 WET and 08:00 PST, which is correct going forward but not correct last week.

I expect that in a few weeks, Repeating Event A will switch back to 15:00 WET and 07:00 Pacific when WET switches to DST. But you wouldn't know it looking at the calendar today.

I suppose it is behaving correctly at one level. But is horrible for planning purposes.

[Mika Koivisto, módosítva 10 év-val korábban]

The DST issue is known and being addressed in LPS-43876.