Need some guidance on setDefaultDisplayTimezone()

[mathias]

Hi, i'm currently looking into enabling uses to configure local timezone in case they're travelling abroad.

I tried the abovementioned call and it seems to work, but i have some issues.

1. From what i can see from the smartclient docs, this is *only* supported for datetime fields? What about time fields, is there any way to leverage this functionality for that type of field?


2. i have some places where i have a custom cellformatter on the datetimefield, for example:

public class WPOutTimeFormatter implements CellFormatter {

    @Override
    public String format(Object value, ListGridRecord record, int i, int i1) {
        if (value != null) {
            GWT.log("the date i got in is " + value);
            return DateUtils.lengthWithPlusDates(record.getAttributeAsDate(CSConstants.FIELD_INTIME), (Date) value);
        }
        return "";
    }

The problem is that the Date value that comes in the value Object is the 'regular' date. Is there any way to have a custom formatter like this but make it work with a custom timezone?

Help appreciated.

[Isomorphic]

1. It works for both time and datetime

2. Changing the display timezone does not change the underlying date value (that would be a bug!). The formatters we provide will use the configured display timezone, and since we support SimpleDateFormat, you can probably get whatever you want out of those. Or just use GWT's DateTimeFormat, which also supports being given a timezone.

[mathias]

1. That's great, thanks! (The smartclient docs on Time.setDefaultTimeZone says "Sets the offset from UTC to use when formatting values of type datetime with standard display formatters.Sets the offset from UTC to use when formatting values of type datetime with standard display formatters." - not complaining, just that it was enough to confuse me, as evidenced. Not that it takes much...)

2. Perhaps you'll allow me to give you my usecase and see if you have any tips?

The use case is to, in a listgrid that shows "workperiods" with an in- and outtime. I show intime with a standard date formatter, but for the outtime, which also is a datetime, i have a calculation that shows the out time as "09:00" for example if same day, but "09:00 (+1 day)" if it's x days later

i have of course solved this with a cell formatter as you see in my example, where i put it on the "out" field, but i also need the "in" field which i then get with getattributeasdate, and call the function

public static String lengthWithPlusDates(Date inTime, Date outTime){
        int daysBetween = CalendarUtil.getDaysBetween(inTime, outTime);
        String plusdates = daysBetween > 0 ? " (+" + daysBetween + "d)" : "";
        return formatTimeDisplay(outTime) + plusdates;
    }

So, do you have any tips on how to achieve this? I have other places where i have simular situations with cell formatters. Is my only choice to get the raw values out and do tons of timezone-calculations myself?

[Isomorphic]

1. Sorry, we went to update the docs and realized we misspoke - the docs are already correct, and timezone offset does not apply to the "time" type because it is a logical time, like "all Hyatt hotels serve breakfast at 9am".

2. This is a pretty run-of-the-mill coding exercise - we would recommend using AI to generate the code if you're having trouble.

[mathias]

Regarding point 2 and "run of the mill"

a) Do you mean changing the 15-20 different cellformatters, using different fields of different datasources i have (some who are quite more complex than my example above), to take into account whether the timezone has been altered. Remembering and making sure that it's done everywhere?
b) Handling daylight saving times, half hours etc, and the quirks that come with it everywhere in my app?

(no i wouldn't actually consider that "run of the mill", thank god there is AI to do everything for me flawlessly)

*Of course* everything can be done, but the problem is far from only how hard it is to do the *actual calculation*, it's practical stuff like point 2 - maintenance, remembering to do things every time i do formatters etc, avoiding boilerplate code, etc.

---
To be honest - When i first read about this timezone method, i assumed that when a value is set, it would then use adjusted times *everywhere* in the system, and just convert back and forth when communicating with the server. I mean, the form fields for example use the changed values too.
---

Let me be more specific:

1. is there a way or method to get the adjusted datetime values out from a datasource based on the timezone, that is the value you use yourself for displaying values? Surely you do the adjustments *somewhere* since you present them? For example, being able to actually set the cellformatter to get the adjusted values would be useful.

2. Where do i get the configured timezone out? I can only find setDefaultDisplayTimezone, no getter.


One final comment re. your "that would be a bug" comment in your first post: It could be argued that if you go to the trouble of setting "setDefaultDisplayTimeZone" in a system-wide call, the value that comes in to cell formatters is the adjusted value. But i'm probably missing something.


We're seeing a bunch of issues in our Calendar timelines too that i was going to ask about, but let's not bother this seems like too much work.

[mathias]

I might as well say what our calendar issue is in case it helps. If you look at your "simple timeline" example: https://smartclient.com/smartgwt/sho...imple_timeline

The timeline normally shows all events as taking up the whole day, regardless of when they begin and end.

But if you adjust it with the method we're discussing, like this:

public class SimpleTimelineSample implements EntryPoint {

    public void onModuleLoad() {
        DateUtil.setDefaultDisplayTimezone("+05:00");
        Timeline calendar = new Timeline();
        calendar.setHeight(451);
        calendar.setStartDate(new Date(116, 5, 2));
        calendar.setEndDate(new Date(116, 5, 22));
        calendar.setCanEditLane(true);
        calendar.setShowEventDescriptions(false);

        HeaderLevel[] headerLevels = new HeaderLevel[]{
            new HeaderLevel(TimeUnit.WEEK),
            new HeaderLevel(TimeUnit.DAY)
        };
        calendar.setHeaderLevels(headerLevels);
        calendar.setLaneFields(new ListGridField("title", "Developer", 120));
        calendar.setLanes(TimeLineData.getRecords());
        calendar.setData(TimeData.getCalendarRecords());

        calendar.draw();
    }
}

All entries get offset, like in the screenshot below.

[Isomorphic]

Please read the Date & Time Format and Storage overview. The datetime values are not adjusted (that would be an incorrect implementation), so, you seem to think we are "hiding" some information that we have, but we are not.

All we do is provide a way to format dates in a particular timezone, which is also a core capability of GWT's DateTimeFormat.

As far as your 15-20 different cell formatters, we're not sure what point you're making. As a reminder, we are not here to write code for you (and you don't even have Support!).

All we can say here is:

1. you can probably get rid of at least some of them, via using our DateUtil utilities and/or DateTimeFormat

2. you will need to figure out your application-specific notion of whether something is in the "next day" when you are viewing from another timezone. We would not recommend re-implementing that logic 15-20 times in different formatters, rather, call a common utility method you write once.

[mathias]

Well, in that case, thanks for taking the time to respond in the forums even though i don't pay for support.

I don't think we'll get further so have a good one, if we set the timezone i guess we'll have to live with the calendar looking the way it does.