I have a case that I need to check the time difference by days between date from receipt and current date. For current date we have been using created session variable NQ_SESSION.Current_date.
So I have a calculated field in OBIEE:
TIMESTAMPDIFF(SQL_TSI_DAY, "Time"."Date", VALUEOF(NQ_SESSION."Current_date"))
The problem is that I need to check time difference for only for days 1.5.-30.9. for each year. So a case example:
RECEIPT_DATE = 1.3.2020
CURRENT_DATE = 26.4.2022
RESULT should be number of days from periods 1.5.2020 - 30.9.2020 and 1.5.2021 - 30.9.2021 --> 152 + 152 = 304
Is there any way to do that in OBIEE?
Related
In my cube, I have several measures at the day grain that I'd like to sum at the day grain but average (or take latest) at the month grain or year grain.
Example:
We have a Fact table with Date and number of active subscribers in that day (aka PMC). This is snapshotted per day.
dt
SubscriberCnt
1/1/22
50
1/2/22
55
This works great at the day level. At the month level, we don't want to sum these two values (count = 105) because it doesn't make sense and not accurate.
when someone is looking at month grain, it should look like this - take the latest for the month. (we may change this to do an average instead, management is still deciding)
option 1 - Take latest
Month-Dt
Subscribers
Jan-2022
55
Feb-2022
-
option 2 - Take aveage
Month-Dt
Subscribers
Jan-2022
52
Feb-2022
-
I've not been able to find the right search terms for this but this seems like a common problem.
I added some sample data at the end of a month for testing:
dt
SubscriberCnt
12/30/21
46
12/31/21
48
This formula uses LASTNONBLANKVALUE, which sorts by the first column and provides the latest value that is not blank:
Monthly Subscriber Count = LASTNONBLANKVALUE( 'Table'[dt], SUM('Table'[SubscriberCnt]) )
If you do an AVERAGE, a simple AVERAGE formula will work. If you want an average just for the current month, then try this:
Current Subscriber Count =
VAR _EOM = CLOSINGBALANCEMONTH( SUM('Table'[SubscriberCnt]), DateDim[Date] )
RETURN IF(_EOM <> 0, _EOM, AVERAGE('Table'[SubscriberCnt]) )
But the total row will be misleading, so I would add this so the total row is the latest number:
Current Subscriber Count =
VAR _EOM = CLOSINGBALANCEMONTH( SUM('Table'[SubscriberCnt]), DateDim[Date] ) //Get the number on the last day of the month
VAR _TOT = NOT HASONEVALUE(DateDim[MonthNo]) // Check if this is a total row (more than one month value)
RETURN IF(_TOT, [Monthly Subscriber Count], // For total rows, use the latest nonblank value
IF(_EOM <> 0, _EOM, AVERAGE('Table'[SubscriberCnt]) ) // For month rows, use final day if available, else use the average
)
I want to update ends_at column of subscriptions table. When i use
Carbon::now()
It update perfectly but when is use
Carbon::now()->addCenturies(5);
I am face error
SQLSTATE[22007]: Invalid datetime format: 1292 Incorrect datetime value: '2520-08-07 11:39:13' for column 'ends_at' at row 1 (SQL: update `subscriptions` set `ends_at` = 2520-08-07 11:39:13, `subscriptions`.`updated_at` = 2020-08-07 11:39:13 where `id` = 1)
i want one subscription for life time due to this i think add centuries. kinldy tell me solution my controller code is
$subscription = $user->newSubscription('default', $plan->plan_id)->create($request->paymentMethod, [ 'email' => $user->email ]);
$subscription->ends_at = Carbon::now()->addCenturies(5);
$subscription->save();
The TIMESTAMP data type is used for values that contain both date and time parts. TIMESTAMP has a range of 1970-01-01 00:00:01 UTC to 2038-01-19 03:14:07 UTC. Your given year is 2520 and your MySQL can handle year as max 2038.
Change the migration timestamp to dataTime format as :
$table->timestamp('ends_at');
to
$table->dateTime('ends_at');
It looks like ends_at is meant to be managed for you by Laravel Cashier, not something you modify manually. Reviewing the source code, it is only updated based on other values, not any parameters. It also is not used to set any parameters in Stripe API requests. The cancel_at parameter would seem to most likely mapping.
If you wish to set cancel_at, it takes an epoch timestamp (in seconds). As #sta mentioned above, this has a maximum value of 2147483647, representing a time in 2038.
Note also that Subscriptions will by default continue in perpetuity, so it is not necessary to set an "end date" 5 centuries from now.
The current function in use in the JMeter script is
${__timeShift(dd/MM/yyyy,${__time(dd/MM/yyyy)},-P31D,,)}
to specify a review date 31 days ago.
I now learn that the project requires the review date to always fall on a Monday. Is there any way to make sure that performing a timeShift only selects a Monday?
I'm afraid __timeShift() function is not flexible enough, you can consider using __groovy() function instead and implement the following algorithm:
Get current date
Subtract 31 day
If current day of week is Monday - return the date in the past
Otherwise add 1 day until the date in the past becomes Monday
Example function code:
${__groovy(def now = new Date(); def monthAgo = now.minus(31); while (monthAgo[Calendar.DAY_OF_WEEK] != Calendar.MONDAY) { monthAgo = monthAgo.plus(1)}; return monthAgo.format('dd/MM/yyyy'),)}
Demo:
More information: Apache Groovy - Why and How You Should Use It
I have column which stores only time. I want to convert to it into datetime and then to a specific timezone. When I do it on console using only the attribute, it shows correct conversion value. But when I use it in query the query shows the current time in UTC. Suppose I have time "05:15" stored in Central time. Now when I want to fetch records for a interval of 30 minutes plus and minus of this time, I do following,
day = Time.now
# departure_time_from _db below is the name of column in table which store time
departure = departure_time_from _db.change(:day => date.day, :month => date.month, :year => date.year)
departure = departure.in_time_zone("Central Time (US & Canada)")
When I execute above code on console and see the value, it shows correct converted value. But when I use this variable in below query, current time gets used instead of the departure time.
Model.where("column_name > ? and "column_name < ?, departure - 30.minutes, departure + 30.minutes)
The time used in above query should be the time I want i.e Central time zone, but in query output, it shows UTC being used.
Please let me know what i am missing.
It shouldn't matter what time zone the query uses in the where clause as long as it's the same time representation. The time you're seeing in your query output from Rails is most likely the UTC equivalent of the ruby DateTime object being passed to the where statement. So if departure is 12:00 noon (UTC -6) in your Ruby code then the time shown in the SQL query will be 18:00, which corresponds to noon CST.
I have a column with data year&week. I would like to create a date axis based on this.
when i try to format the date, it is not working
I tried this:
var parseDate = d3.time.format("%Y-%W").parse;
d3.csv("temperatures_groups_2.csv", function(error, data) {
data.forEach(function(d,i) {
d.timestamp = parseDate(d.timestamp);
alert(d.timestamp);
d.temperature = +d.temperature;
}
});
i get null when the alert executes.
If i replace the same with d3.time.format("%Y-%m").parse, it works fine. It takes the month but not week no.
The csv contains data like this
timestamp,temperature
2013-01,19.5
2014-02,21.5
2015-03,20.5
2016-04,20.5
2017-05,21.25
The documentation says:
The following directives are not yet supported for parsing:
%U - week number of the year.
%W - week number of the year.
Hence you can't use D3 to parse these dates. You'll have to parse the date yourself or use another library, for example moment.js.
This works since version 3.2 and the documentation has been updated.
%U - week number of the year (Sunday as the first day of the week) as a decimal number [00,53].
%W - week number of the year (Monday as the first day of the week) as a decimal number [00,53].
However, the format in your question won't work because the parser requires a specific date to be specified. E.g. by "%a". It would be nice to assume Sunday in the absence of a date specifier, but that's for another PR.