Change WebDateField to use new Java 8 date-time API

[mokun]

I'd like to change the timezone from PDT (currently the system default timezone on my machine) to UTC.

I've tried using setDateFormat(d) but it doesn't change it to UTC. Still showing PDT.

See attached pic below :

This is my codes :

WebDateField earthDateField = new WebDateField(StyleId.datefield);
DateFormat d = new SimpleDateFormat("yyyy-MMM-dd  HH:mm a '['z']'", LanguageManager.getLocale());
earthDateField.setDateFormat(d);
...

Note that I know the [PDT] shows up because I put ['z'] in the formatting string inside the SimpleDateFormat

If I switch from the lowercase z to the uppercase Z (from ['z'] to ['Z']), it will display [-0700], which is the time offset from the UTC.

See attached pic below :

So it doesn't help.

My purpose is to make the timestamp showing the UTC time. So at the start of my app, it should show the UTC time of 2028-Aug-17 03:24 PM [UTC].

I'm still on v1.2.10.

Thanks for any inputs !

[mokun]

Never mind. I just figure out I need to call the following to change the system default timezone to UTC with

DateFormat d = new SimpleDateFormat("yyyy-MMM-dd  HH:mm a '['z']'", LanguageManager.getLocale());
d.setTimeZone(TimeZone.getTimeZone("GMT"));

It works now :

I'd like to ask one more question here.

Since I've been converting my app to use the new Java 8 time API, will weblaf's WebDateField be supporting the new Java 8 also in near future ?

In my app, now I have to convert the new ZonedDateTime back to the old Date API every time I update the time.

earthDateField.setDate(new Date(zonedDateTime.toInstant().toEpochMilli()))

I'm thinking it would be a lot simpler to accept the my zonedDateTime in future if it's possible : earthDateField.setZoneDateTime(zonedDateTime))

[mgarin]

Since I've been converting my app to use the new Java 8 time API, will weblaf's WebDateField be supporting the new Java 8 also in near future ?

Will it be supporting new Java 8 time API? - yes, certainly In near future? - at least not in the next few updates for sure, no

I do plan moving the whole library to Java 8+ support for sure, there are A LOT of things I can improve once it's done, including new time API, NIO usage, lambdas, lots of workaround code can be removed etc. And I've already been adding bits for Java 8 users here and there across the library code.

But there are quite a few things that needs to be finished in the current version before I can move on because once I do - features won't be backported to Java 6 version, only fixes. So library needs to be left in a polished and complete state before I do that.

I was thinking about maybe adding a separate branch for Java 8 stuff and start working on that in the background, but that will add a lot of extra work on top of current things that needs to be completed, so probably not happening until I'm done with Java 6 version.

[mgarin]

I'll change this to enhancement request for the future change to Java 8 date-time API.

[mokun]

@mgarin

I just found out that the tooltip cannot be used for the WebDateField.

I have an instance of WebDateField called earthDateField and did the following : TooltipManager.setTooltip(earthDateField, "Earth's Timestamp", TooltipWay.up);

However, when I hover over the earthDateField, there is no tooltip.

I was also looking up the static method setTooltip :

    public static WebCustomTooltip setTooltip ( final JComponent component, final String tooltip, final TooltipWay tooltipWay )
    {
        return setTooltip ( component, tooltip, tooltipWay, defaultDelay );
    }

Can you take a look to find out why ?

[mgarin]

I don't really need to look into it to tell the answer - this happens because WebDateField itself is simply a Container for the actual text field & button in it. Setting the tooltip directly on WebDateField doesn't work because 99% of the time you hover the editor field or the button, the only exception is the thin border around them (in case WebDateField is decorated) on which you might get the tooltip you set.

Same applies to all other components that are simply containers for the actual visible components.

I don't really have a solution for this at the moment. This is something I will need to think about and find a way to make it work internally. But it won't be coming in the next update - I will add this along with the TooltipManager revamp I will be doing in one of the future updates.

As this problem doesn't really belong to this thread - I've opened a separate issue: #605 - I suggest further discussions on the matter to be held there.

As for the TooltipManager improvements - there is already a general issue containing the list of planned improvements, you can check it here: #520