bug in primefaces calendar timepicker? - jsf

I have this calendar with time picker on my page:
<p:calendar value="#{addTaskBacking.currentTask.deadline}" mode="inline"
pattern="dd-MM-yyyy HH:mm" mindate="01-09-2013 00:00"/>
When I set the pattern: dd-MM-yyyy without the time everything is added correctly, but when I change to: dd-MM-yyyy HH:mm I get this error:
j_idt10:j_idt12: '9-04-2014' could not be understood as a date and time.
This is when I set the inline mode, when I set the popup is all ok.
I have primefaces_v4.jar. I check this side http://forum.primefaces.org/viewtopic.php?f=3&t=22982 but i can't find any solution
Edit:
It look like all depends of mode atribute of p:calendar. If i have default popup mode everything it's fine (like in example on http://primefaces.org/showcase/ui/calendarTime.jsf. But when I change to inline mode i get this error:
cal:inlineCal: '13-04-2014' could not be understood as a date and time. Example: 13-04-2014 15:16

PrimeFaces uses SimpleDateFormat by default unless you override the formatter.
http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html
EDIT
Your pattern will work if you change your mindate attribute to be the same as your pattern..
IE: You can't have a pattern dd-MM-yyyy HH:mm when you have a mindate="01/09/2013"
Change your mindate to - 01-09-2013
EDIT 2
AFter debugging a fair bit you're right, there seems to be a bug when setting the inputValue field in javascript prior to being sent in the POST to the server to even use the pattern converters...
I got it all working recompiling the code with the following changes:
Line 129 in calendar.js (gets merged into primefaces.js) var newDate = this.value;
Basically at the moment it tries to do a formatDate on the input which is fine cause its the same date format split ie, dd/mm/yy etc.. but it totally skips 'time' being attached can't use parseDatetime as it does an entire object time, which should be don eon the java side as you just build the object.
this.value is what you want regardless to be sent back in the post which is what it does for _self.cfg.popup (it doesn't even set the input val because its already there!...
I'll raise an issue with PF
"Raised Issue 6790 on the PrimeFaces Issue Tracker"

Related

Issue of Reading and Converting Date of Google Calendar Events when language is set to Arabic in C#

I am Using Google APis .net client library to read calendar events.
I have following line of code
newRow["Start"] = pEventItem.Start.DateTime.HasValue ?
Convert.ToDateTime(pEventItem.Start.DateTime) : Convert.ToDateTime(pEventItem.Start.Date);
Where PEventItem is of type Google.Apis.Calendar.v3.Data.Event and NewRow[...] is of type DataRow. The Value of pEventItem.Start.Date is "2019-06-24" (as seen in debug window)
The above line of code works perfect, But fails when UI language / Culture is set to Arabic (SaudiArabia) The same Convert.ToDateTime throws error "String was not recognized as a valid DateTime".
btw, How i am changing the UI language is as below for your information.
Thread.CurrentThread.CurrentCulture = System.Globalization.CultureInfo.GetCultureInfo(ChangeLanguageTo);
Thread.CurrentThread.CurrentUICulture = System.Globalization.CultureInfo.GetCultureInfo(ChangeLanguageTo);
I tried to set 2nd parameter of the Convert.ToDateTime function in an hope that it will convert date correctly...
CultureInfo enUsCulture = new CultureInfo("en-us");
newRow["Start"] = pEventItem.Start.DateTime.HasValue ? Convert.ToDateTime(pEventItem.Start.DateTime, enUsCulture) : Convert.ToDateTime(pEventItem.Start.Date, enUsCulture);
Well Now it does not throw exception, but the returned date is incorrect. value retuned is {21/10/40 12:00:00 ص}
while The actual date pEventItem.Start.Date is "2019-06-24"
I also tried invariant culture also, but result is same, converted date is wrong. What could be the issue?
Regards
There are a few things going on here.
Firstly, if you use EventDateTime.DateTime (e.g. via pEventItem.Start.DateTime) you don't need to call Convert.ToDateTime, because that's already a DateTime?... you can just take the Value property to get a DateTime from a DateTime?. However, I should warn that that can perform time zone conversions that you may not want. (We can't fix the library to avoid those, as it would be a breaking change.) Instead, you may want to parse EventDateTime.DateTimeRaw, which is the original string value returned by the API.
When parsing, I'd suggest using the invariant culture using CultureInfo.InvariantCulture (instead of creating an en-US culture), and parse using DateTime.ParseExact, specifying the format you expect based on whether you're parsing a date or a full date/time.
In terms of "the returned date is incorrect" - I believe that's really just the formatted value that's using the default culture, including the calendar system. We can see that at play in the code below, which constructs the DateTime directly (so can't be affected by any text parsing etc). When formatted using the invariant culture, it shows as 2019-06-24, but when formatted with ar-SA, it shows as "1440-10-21" due to the default calendar system for that culture being System.Globalization.UmAlQuraCalendar:
// Note: when a calendar system is not specified,
// it's implicitly Gregorian.
DateTime date = new DateTime(2019, 6, 24);
Console.WriteLine(date.ToString("yyyy-MM-dd", CultureInfo.InvariantCulture));
Console.WriteLine(date.ToString("yyyy-MM-dd", new CultureInfo("ar-SA")));
So what you're seeing in the debugger is the correct date - but formatted in a way you weren't expecting.

querysting binding error when using ServiceStack version 4.0.34 and OrmLiteCacheClient

We're getting an "unable to bind to request" when calling a service with the following querystring:
/SomeService?playerid=59326&fromdate=4-1-2014&todate=12-11-2014
We have been using this querysting format for awhile now.
The problem is some either a change in 4.0.34, or something in the OrmLightCacheClient, which we had turned off for awhile and only just recently turned it back on.
If I change the dates to following format, it seems to work.
/SomeService?playerid=59326&fromdate=2014-4-1&todate=2014-12-31.
We can roll with the changed querystring date format for now, but wanted to report the error.
When supplying a date only (i.e. doesn't include a time) it should be unambiguously defined using the YYYY-MM-DD format.

Search formula not working on Linux machine

I have a strange behavior: an agent called via an AJAX request should search documents to display in a calendar. For that reason I compute a search formula and then run the search method of my database in Lotusscript. This is the formula:
form="mholiday" | form="mserviceevent" | (form="mereignis" & co_status!="9") & #texttotime(#text(startdatetime)) >= [29.09.2014] & #texttotime(#text(enddatetime)) =< [10.11.2014]
Everything's fine on Domino on Windows but fails with "formula error" on a Linux machine. Am I missing something?
If I omit the term with the dates everything is fine, so this is the part that causes the error.
Try it with #ToTime() and #Date() instead. That might help to get away from local settings' influence on server:
... & #ToTime(startdatetime) >= #Date(2014; 9; 29) & ...
#ToTime() doesn't convert the field if it's a date time value already.
#Date doesn't depend on local settings whereas [29.09.2014] probably does.
I don't think it's a Linux problem, I think it's a data problem. It sounds like either a date format problem or a problem with the UNK table, used by full text search.
If the first document created on that server that had a field called "startdatetime" had a text value, then any search expects "startdatetime" to be a text value, even if there is another field in the database called startdatetime that is a date or the startdatetime field is subsequently changed to be a date. To confirm this, you can use the search bar and select the field. The operators it offers will confirm if it's expecting a date or a text value. See this answer for details on how to resolve "Query is not understandable" - Full text searching where field types have changed.
Alternatively, it may be a problem with the date format, as Knut says. In which case a test for 9/9/2014 would work but 29/9/2014 wouldn't.

Problems with jqPlot / Primefaces extender and Date values

so here's the thing.
I've got plenty of persisted "Snapshots" containing a java.sql.Timestamp and (for the sake of simplicity) an int as data.
I have a JSF page containing a primefaces 3.4.1 <p:lineChart> and behind that a ManagedBean that contains the model for the chart.
Let's say I then select a time range and fetch all the Snapshots in between that range.
and populate the data model for the chart with all the Timestamps (x-axis) and all the integers (y-axis).
So what i do while populating is:
data = new HashMap<Object, Number>();
List<Snapshot> allSnapshots = persistenceService.getAllSnapshots();
for(int i = 0; i < allSnapshots.size(); i++) {
Snapshot s = allSnapshots.get(i);
data.put(new Date(s.getTimestamp().getTime()), s.getData());
}
chartModel.getSeries().get(0).setData(data);
(Note: in the example code I just fetch all Snapshots, as I quickly just generated a hundred or so).
I set up the chart like this:
<p:lineChart id="chart" value="#{backingBean.chartModel}" xaxisAngle="-90">
<f:convertDateTime pattern="HH:mm:ss"/>
</p:lineChart>
It works ok but when the model contains a hundred data points, the xaxis is just overcrowded with all the tickmarks.
What I then did is to use the primefaces' option to use a jqplot extender function.
So I just add extender="extend" as attribute for the chart, where extend is the following js function :
function extend() {
this.cfg.axes = {
xaxis: {
renderer: $.jqplot.DateAxisRenderer,
rendererOptions: { tickRenderer: $.jqplot.CanvasAxisTickRenderer },
tickOptions: {
showGridline: true,
formatString: '%H:%M',
angle: -90
}
}
}
}
This is the current version of it..
After hours of reading and trial and error, I still cannot get it right, as the following things are just never right:
The tick marks never get rendered as the Date never gets converted.
At the moment this is just ignored and the formatString itself is
displayed...
Additional tick marks are created left and right of the actual data,
I dont want that.
When I only give autoscale: true as option for the jqplot extender,
I would expect just the spacing between the marks turn ok. But what
then happens is, that the spacing is cool but the original date
labels turn into just bare numbers starting from 0 to the amount of data available.. !?
I am getting a little tired from dealing with this.....maybe I am doing something fundamentally wrong. Otherwise I have no idea why this is so complicated..
Thanks for any advice!
Cheers
Chris
EDIT:
Ok thanks to perissf, I checked this one : https://stackoverflow.com/a/14287971/870122
With the suggested extender I get the following output :
http://www.abload.de/img/clipboard01y6sgj.png
(sorry I cannot post the image directly due to new user restrictions :-/ )
As you can see the tick marks are rendered correctly as HH:MM, thats very nice.
But as you also can see another quite weird problem occurs:
The given time range of the snapshots is
Start time: 2013-01-28 13:01:25.415
End time: 2013-01-28 13:14:32.145
I collected these as UTC timestamps with System.currentTimeMillis() while the JVM is set to UTC in the glassfish config.
As you notice, the datapoints in the plot are shifted one hour, they start at 14:01, which looks like the values have been auto-converted to my current timezone which is UTC+1. But the leftmost xaxis tick is placed at around the original UTC value at 13:00.
I collect the timestamps UTC as I dont know in which actual timezone the application will be running, but I'd like to display the "translated" time value. So the auto shift to my timezone is a nice feature, but the xaxis scaling is actually not nice and weird.
Any suggestions how I get rid of that ?
Cheers
Chris
EDIT2:
Ok while debugging the rendered page with Firebug I stumbled upon the jqplot internal variables in the plot object, which seem to contain the min and max values for the xaxis.
Min is set to the original min UTC value which is around 13:00, and max is set to the shifted UTC+1 value around 14:15.
Somehow the min value is not shifted accordingly to the automatic timezone adjustments.
All other values, that is dataBounds, data itself and so on, are all shifted nicely by one hour.
I opened a issue at Bitbucket jqplot issue tracker
Let's see.
Bye
Chris
i finally debugged the jqplot renderer and found some lines of code that cause this behaviour.
For anyone interested, please find the bugfix in the comment section here:
Bitbucket issue tracker
Thanks for any help
I'm very interested in this fix but the issues on BitBucket are in a restricted area so I cannot access it. So I had myself to try to fix this AxisDateRenderer and fortunately I did :)
So the Primefaces (6.0) chart uses an old version of the JQPlot library. A bug in this version sets the minimum date axis bound being not the first value exactly, but a time older according to the locale time zone of the user browser. For example, if the first value is at 12:00 and your GMT is GMT+1, then the date axis bound minimum will be at 11:00 instead of 12:00 !
The minVale
The following line (in createTicks function) should bed replaced (note the code is written minified below)
ad = ad.getTime() + ad.getUtcOffset();
By the next line:
ad = Math.floor((ad.getTime() - ad.getUtcOffset())/r) * r + ad.getUtcOffset();
Non minified line to replace:
min = min.getTime() + min.getUtcOffset();
With:
min = Math.floor((min.getTime() - min.getUtcOffset())/tempti) * tempti + min.getUtcOffset();
Note that I have tried to update the chart.js of Primefaces to an earlier version , but the chart do not work anymore. I will wait for the next update of Primefaces hoping that a newer version is used. I also don't know which version of JQPlot is used in Primefaces 6.0

input control not visible in jasper server, groovy expression might be the issue

(
$P{cal}.clear() ||
$P{cal}.set(Calendar.YEAR, $P{year_current})||
$P{cal}.set(Calendar.WEEK_OF_YEAR, $P{week_current}) ||
$P{cal}.setFirstDayOfWeek(Calendar.MONDAY) ||
$P{cal}.setMinimalDaysInFirstWeek(4)
)
? null : $P{formatter}.format($P{cal}.getTime())
The above code calculates the start date from ‘week_current’ and ‘year_current’ input’s. The problem is that the code calculates the startDate in ireport but not in jasper server.
When I run the report on jasper server, the display mode (pop-up window) comes up blank without any input controls.
But when I change the above code to match one of your date calculations,the same report runs without any issues on jasper server i.e, the display mode (pop-up window) shows the defined input controls.
I would appreciate if you can let me know what is wrong on my date calculation expression which is preventing the input controls to appear on jasper server.
I found a solution to the problem, you need to pass the class java.util.Calendar as parameter:
http://type-exit.org/adventures-with-open-source-bi/2010/06/date-calculation-in-ireport/

Resources