Calendar functions in the showcase not working from Linux system (firefox or chrome)

[cennever]

I've been running a few tests in the smart-client showcase on the various calendar objects. When accessed from a Linux platform (centOs/redhat) using either firefox or chrome, both the day and week views appear disabled (greyed out) after 10:30am on the screen. They all work fine when called from a windows OS. Any advice/feedback would be greatly appreciated. Thanks Col.

After further tests it looks to be some sort of timezone issue. If the source Linux sever it set to my local TZ of +11 (Sydney time) the calendar in showcase (24 hour based sample) is greyed out from 11am. I tried changing the source Linux server to a -8:00 TZ (LA time) and the greyed out section from 11:00 on is now gone. Any feedback appreciated. Thanks Col.

[cennever]

After further tests it looks to be some sort of timezone issue. If the source Linux sever it set to my local TZ of +11 (Sydney time) the calendar in showcase (24 hour based sample) is greyed out from 11am. I tried changing the source Linux server to a -8:00 TZ (LA time) and the greyed out section from 11:00 on is now gone. Any feedback appreciated. Thanks Col.

[Isomorphic]

1) what version of SmartGWT are you using? (version and build-date, displayed in the Showcase, bottom left)

2) is there a specific sample, or test-case you're using?

3) when you say "greyed out", are the cells actually disabled, or just styled? If you set disableWeekends: false, what happens?

4) what date are you're viewing?

[cennever]

Thanks for the reply:

1. Showcase Version: 5.1p
Build Date: Friday Feb 19 (http://www.smartclient.com/smartgwt/.../#calendar_24h )
and
Showcase version: 10.1p
Build Date: 2016.2.17 (http://www.smartclient.com/#simpleDayLanes)

2. The easy sample to see the issue is : "24h base calendar" (under calendars).
NOTE: Our specific issue is with the day lanes calendar. It has the same issue, it just looks a little different. The 1st lane is all greyed out (disabled), other lanes are greyed out from 11 on (whenTZ is +11).
We tried a few more zones and found the greyed out section advances with the TZ offset. eg: When we used Australia Perth TZ (+13), the greyed out section started at 1:pm (13:00 24h time). From what I've seen so far it looks like any TZ with a (+) off-set will act in this way when using a browser run from a Linux source system. I will follow up with some screen grabs of the day lane calendar a little later.

3. When I inspect the greyed out element it shows as .calanderDisabled. Its as if the calendar thinks the day ends at the TZ offset.

4. Any date ant the same issue (day or week view). I was was viewing week ending 20th Feb

Also we have tried several versions of Firefox & chrome (linux) all have the same issue.

Again thanks for the response. A resolution would be greatly appreciate.

Col.

[cennever]

Further to the post above I have attached 3 screen grabs. These were taken from a Linux system (CentOS release 6.5 (Final). The TZ of the system was NZDT +13. I've circled in red where the calendar is disable (1:00pm on with this TZ or 11am when in AEDT +11 TZ).

1. day_lane (SmartClient) (This is the one causing us the issue). With the daylane calendar only the 1st column has the disabled cells however the other columns don't show events after 1:00pm even though they are enabled.

2. Work_day (SmartClient) : The disabled cells are in the white section for this one.

3. 24h (SmartGWT): The disable cells are grey for this one.

All 3 sample appear to have the same issue from 1:00pm with a TZ of +13.

Thanks,
Col.

[Isomorphic]

Are you saying we should be able to see these issues by just changing the system TZ to GMT +13?

We don't see any of these bad behaviors in SmartClient or SmartGWT if we do that, in the online showcase or locally.

Are you doing anything else? Calling setDefaultDisplayTimezone(), for example?

[cennever]

To see the behaviour as shown in the screen grabs you needs to be:

1. Accessing the showcase using a Linux installed browser (firefox or Chrome). I could see the issue in both redhat and CentOS installs.
2. Have a TZ of lets say ADST (+11). New Zealand TZ (+13) is fine also. The disabled section just moves two hours later.

You won't see the issue with any TZ using a windows installed browser. The issue appears to be centric to Linux browsers with a (+) TZ offset.

Thanks for the follow up. This is a big issue for us right now.

Col.

[cennever]

Also just to be clear, the showcase tests I have been running are all from the current isomorphic website. Not a downloaded showcase version.

http://www.smartclient.com/smartgwt/.../#calendar_24h
http://www.smartclient.com/#simpleDayLanes

Thanks,
Col.

[cennever]

Just checking if any further insights to this issue have been found.

Thanks,
Col.

[Isomorphic]

We do see this issue on a CentOS box set to NZDT - we'll take a look, but the issue is queued behind other issues reported by customers with support contracts (http://www.smartclient.com/services/index.jsp#support).

[Isomorphic]

The problem here is deep in our logic for detecting which rows in a vertical calendar, if any, represent time lost or gained during the crossover between standard time and DST, in those places that recognize it.

That's assigned to be fixed properly, but we're not there yet.

In the meantime, we've added a new attribute, Calendar.ignoreDST - set this to true to prevent all of our custom DST logic (which is responsible for disabling and styling those bad cells, among other things). That will get things working so you can sensibly test and develop Calendars.

Note that an attribute like this has been on the roadmap for a while - but it's not yet public because it's not fully implemented, so it is subject to change. In this case, it's a temporary workaround anyway.

Can you let us know which product you're intending to use, SmartClient or SmartGWT? Your post refers to online samples from both.

From tomorrow, this new attribute can also be used on the SmartClient online showcase samples, where sample-code can be altered, but not the SmartGWT ones.

[cennever]

Our UI application is built with SmartGWT however our view definitions are stored as SmartClient JSON definitions and instantiated with the SmartClient libraries. So as long as the new SmartClient libraries are included in SmartGWT build and therefore contain the new attribute (“ignoreDST”) in the core we should be fine.

We currently use version SmartGWT 5.0 (SmartClient libraries 10.0). Has this new attribute been included with this version?

We can upgrade to upgrade to 5.1 / 10.1 without much fuss though.

Thanks,
Col.

[Isomorphic]

Certainly, if upgrading is possible at all, we would advise doing that, for several reasons:

1) 5.1 is the current live branch; it has all the latest released features
2) the greater the delta between our live release and your dev release, the greater the chance that fixes and, in rare cases, new features will *not* be portable
3) in the specific csae of Calendar/Timeline - this widget-set went through a major overhaul between 9.1 and 10.0 - so, in 5.0, you're effectively working with NewCalendar 1.0.

That aside, we just ported this particular change back to 5.0/10.0 - but only this initial part, which literally just prevents our DST detection logic from running in the first place. You can test it out in 5.0 tomorrow.

Note that you can always use setAttribute() in cases like this - Calendar.setAttribute("ignoreDST", true) - from custom SmartGWT code - we were just noting that you couldn't do that in the online showcase, because that code is immutable.