I'm trying to add a parameter on pentaho report designer and I don't quite understand one thing:
I have a table where there are information of clients over two months. So one person appears two times.
And I want to make a parameter of month.
However when I set up the parameter by choosing month, on the selection window, it shows 03 04 03 04 and more.
All I want is one time of 03 and one time of 04.
I can't figure out where the prob is coming from.
Anyone has in idea please? Thanks a lot !
Related
I have a scheduling system on which several people schedule activities, by adding to a Google Sheet event_id, start_date, finish_date and start_time (HH:mm). This goes through various validity checks, including matching start_time to a list of valid start times on another sheet.
This works. But some of these activities are between midnight and 6am, and are therefore scheduled as belonging to the day before and sorted to the end of the daily list, not the beginning.
I do this by, for example, entering 01:30 as 25:30, which then displays as 01:30 and stores as Sunday Dec 31 1899 01:30:00, and all works as it should.
But when other people enter start times, they will often forget the instructions and enter the start time as 01:30, which does not match the validation and further processing. What I am trying to achieve is an automatic change to such entries, such that one day is added and the system stores Sunday Dec 31 1899 01:30:00, which matches the validation.
But it doesn't. Entering 25:30 by hand works perfectly, but entering 01:30 and then passing it to:
if (stime.getDay() == 6 && shr < daystart){
stime.setDate(31);
osheet.getRange(activerow,7).setValue(stime);
appears to work, but then does not match the validation grid.
I have tried numerous ways to add the 24 hours, such as
stime.setDate(stime.getDate()+1);
but all with the same outcome. A manual input of 25:30 checked for equality against the appropriate cell in the validation grid returns TRUE; any computational method returns FALSE on the same test.
I am clearly doing something stupid, but what?
Thank you for reading this.
It's always the way. Give up, ask for help, and then the answer occurs to you. There is a calculation error somewhere; the calculated value differs from the manual input from the 11th decimal place onwards. So, surrounding both parameters in the validation check with a =ROUND(stime,8) etc, will fix it. Sorry to have wasted your time. But I'll leave this here in case anybody else has a similar problem.
I have a simple system, which on node creation form, allows user to select start and end dates along with hours and minutes:
The problem is that the date gets messed up somewhere in the middle, or I don't know how to convert it.
In the database, two values gets saved as follows:
start: "2019-08-01T14:00:00.000Z"
end: "2019-08-01T16:00:00.000Z"
Seems correct, as in the datepicker I chose 2pm and 4pm. Then, using momentjs and react-big-calendar, I try to put that event into calendar. It seems that it puts +3 hours every time. I assume, it is because it saves it in UTC format, and I live in Eastern Europe, which is +3 hours from UTC.
What is strange, is that I already get back time converted to my own when I make a request to the database:
Thu Aug 01 2019 17:00:00 GMT+0300 (Eastern European Summer Time)
Could someone help me out? I would expect to have the same hours returned and displayed, as I save them, meaning if I select 2pm, it should be 2pm. I think the solution here would be to ignore timezones, and always display everything in UTC? But how to do that? I have access to momentjs if that helps. I tried something like this:
moment.utc(event.start);
But it still returns the same value, which is:
Thu Aug 01 2019 17:00:00 GMT+0300 (Eastern European Summer Time)
When you setup React-Big-Calendar, you define a localizer. By default, the calendar will display in the local timezone of the browser the user is using. Any and all dates given to the calendar will be converted to that local timezone. If your dates, coming from the db, use an offset of +5, but you're sitting in +3, it will automatically convert those times to display +3 (part of the beauty of UTC).
This is where it can get tricky. Say I want to get all values from my db between Sep 19th and Sep 21st. I have to remember those offsets when requesting data from the system. I could use moment and say moment('2019-09-19').startOf('day'), and it would give me 2019-09-19T00:00:00Z, but this isn't exactly correct for me, as I'm at an offset of -5, which means I actually needed 2019-09-18T19:00:00Z to get the start of my day. The same holds true for my end datetime, where I would say moment('2019-09-21').endOf('day') and it would give me 2019-09-21T23:59:59Z, when I would need 2019-09-21T18:59:59Z.
Now, I'm not positive of this (you'll have to do some testing), but if you use moment-timezone instead of moment it may handle all of this for you. You'll have to play around to know for sure.
FINAL EDIT: I worked out timezone handling with moment-timezone as my localizer. I put the entire thing in a GitHub project, as well as creating a CodeSandbox where people can play with it.
TRULY FINAL EDIT: The (0.36.0) latest version of RBC has full timezone support now, when using either the momentLocalizer or the new luxonLocalizer. Doc site isn't up to date yet, but if you run the 'examples' locally you'll find all the info.
Setting up a new website using CSS3 and I'm toying with a modal. For content, I'd want to put in a number (113) that would have an additional 113 added to the current number daily, resetting at January 1 each year.
For example... it's currently June 13. 18,532 would be the current number displayed, if my sleepy brain is right, and tomorrow it would be 18,654, and the day after, add on another 113, and so on. I'd like something that would do that daily without me updating it, the opposite of a countdown. I do NOT know how to script these things. Does something open source and user-friendly like this exist?
I want the user to enter dates, not times, just dates, using a datepicker. Doesn't seem too hard, but it's killing me.
I choose the 1st of December on the datepicker and click Save. In the Network tab on Chrome, I can see the data sent to the server has the value: 2015-11-30T22:00:00.000Z
On the server, while debugging I can see the value in the Date field is 30/11/2015 22:00:00.
This will then get stored in a Date column as 30 November 2015 and is wrong.
Where is the issue: the configuration of the angular directive, or the configuration of JSON.NET's deserialization? And how do I fix it?
Obviously quite a common question, I just needed to search a bit better.
In the end I've implemented this directive, which modifies the model used by the datepicker:
https://gist.github.com/weberste/354a3f0a9ea58e0ea0de
I am a newbie in Infopath & Sharepoint. I am trying to create a form from Infopath 2013 and publish it as a document library to Sharepoint. I have some 60 fields that needs to be calculated(add) into another field. When tried to use the Design Checker, it throws an error as mentioned below in the screenshot. But it accepts if I key in only 45 fields in the Insert Formula text area. Is there any limitation on number of fields to be entered in Insert Formula? When I use PREVIEW in Infopath it works fine. This error pops up only when I try to publish it to Sharepoint. Any ideas on how to resolve this? - Thanks inadvance
InfoPath preview is rendered with IP Filler. The Browser experience has always been different, and the Filler preview is not a reliable check for the browser experience. You may have hit the limits of what a browser form can do. I don't have the numbers or limits, though.
Looking at the error message, you seem to be amassing an awful lot of calculations in one single field. My gut feeling is that this is very bad information architecture. What is the purpose of the form? What are you trying to achieve? Why would anyone have 60 fields in a form?
It looks as if you are summing a large number of cells. InfoPath is not a spreadsheet.
Use repeating tables to capture similar data. Then you can total the table entries with a standard IP function.
This looks like a sum of all the items a restaurant has on the menu. This is a perfect case for a repeating table. Don't use all 60 items on the menu in a list of 60 fields all in one form. That is overkill and not user-friendly. Create a repeating table structure where the user selects one of the 60 items and enters the transaction data. Each row of the repeating table can have another item of the list of 60. The grand total will be calculated from the entries.
If that is not viable, use helper fields to calculate sub totals by item category, and create a grand total from all the category totals.