Jump to content
Sign in to follow this  
Blesta Addons

Dates in blesta should have a fix,

Recommended Posts

Hello, this is not the first time i talk/claim about this, but this is causing us a lot of problems and claims and money lose . we talked in

and here

 

but until now no fix is provided .

a sample case from us

Service Created in 10-4-2018 14:00 .

Renew date are 10-4-2019 14:00

Invoice Due Date 10-4-2019 00:00

Suspend Services Days After Due  1 Day

this service will be suspended in 12-4-2019 when cronjob run .

as you see we have here 2 days of latency in suspension system, we need the service to be suspended the same day if invoice is not paid (in our example should be 10-4-2019 14:01) , i wouldn't talk about times in blesta as we have talked a lot and we have arrived to no solution, my ask if blesta staff can make a new setting or anything to achieve this simple request?

we need the service to be suspended after their expiration date immediately, in some services letting services for two days active (and this is the minimum in blesta) before suspending them will consume a lot of resources and licenses fees.

 

 

 

 

Share this post


Link to post
Share on other sites
On 5/6/2019 at 6:45 AM, Blesta Addons said:

as you see we have here 2 days of latency in suspension system, we need the service to be suspended the same day if invoice is not paid (in our example should be 10-4-2019 14:01) , i wouldn't talk about times in blesta as we have talked a lot and we have arrived to no solution, my ask if blesta staff can make a new setting or anything to achieve this simple request?

we need the service to be suspended after their expiration date immediately, in some services letting services for two days active (and this is the minimum in blesta) before suspending them will consume a lot of resources and licenses fees.

Does your Service Suspension automation task run at a later time-of-day than the due date on the invoice for that servce? For example, if the invoice is due at 12:00:00, but the cron runs at 10:00:00 it may not suspend the service because it is still not past 12:00:00.

I think that it would make sense for the Service Suspension task to suspend any service that would be past due (i.e. Suspend Services Days After Due) for the entire day. That is, if the invoice is due May 6 at 12:00:00, but the cron runs May 7 at 10:00:00, it should still suspend it because the invoice was due the day before and the Suspend Services Days After Due is set to 1 day. Would that make sense? It sounds like this might be the issue in your case, except because the cron did not suspend it on May 7 at 10:00:00 it only suspended it the next time the cron ran, the next day, May 8 at 10:00:00.

You mentioned that you want to suspend services immediately based on the invoice due date time, e.g., if an invoice is due at 14:00 and it is now 14:01, the service should be suspended. The problem with this is that the Service Suspension automated task only runs once a day, similar to invoice creation and service renewals, so I would expect them to act on records for the entire day from 00:00:00 to 23:59:59. Sometimes invoices are set to be due at the beginning of the day (i.e. 00:00:00 midnight) even though they may have been created later (e.g. 15:25:00), so the time can not be relied upon like the day can since Blesta focuses on the "day of".

The Suspend Services Days After Due setting does not currently have a "Same Day" option. This is so that customers can pay for the invoice any time on that day (even at 23:59:00) and the service does not get suspended until the next day (at least 00:00:00 the next day). Would a "Same Day" option help you here? It could lead to services being suspended on the day the invoice is due, and depending on when your automation tasks run, before the customer has a chance to pay for it that day.

Share this post


Link to post
Share on other sites

Hello Tyson, from what i have understand it has relation with time and not day, let us simplify it more

invoice due : 10-4-2019 12:00, form what i have capted in your answer the first day due will be at 11-4-2019 12:01 and is illegible to suspension from date 12-4-2019 12:01 if the cron are in in earlier time than 12:00.

it would be a solution if Blesta will not look at time and use only calendar date, i think here we can save 1 day, with a new option like suspended the service same day, so if we have invoice due : 10-4-2019 12:00, cron suspension run time is 00:00, then the service should be suspended in cron run at 11-4-2019 : 00:00. at least with this we have only some hours of delay not whole 2 days.

Share this post


Link to post
Share on other sites
5 hours ago, Blesta Addons said:

it would be a solution if Blesta will not look at time and use only calendar date

I agree that we should be looking at calendar day. I think we can achieve your result by keeping the setting "Suspend Services Days After Due" at "1 Day".

Here's what I would propose:

  • Update the Suspend Services cron to evaluate all services that were due at any time of day yesterday

This would mean that if today is 11-4-2019 00:00:00 and the cron is now running the Suspend Services task, it will see that an invoice was past due at 10-4-2019 23:00:00 (an hour ago) and suspend it now instead of waiting until tomorrow (25 hours after due).

Share this post


Link to post
Share on other sites
On 5/9/2019 at 4:30 PM, Tyson said:

I agree that we should be looking at calendar day. I think we can achieve your result by keeping the setting "Suspend Services Days After Due" at "1 Day".

Here's what I would propose:

  • Update the Suspend Services cron to evaluate all services that were due at any time of day yesterday

This would mean that if today is 11-4-2019 00:00:00 and the cron is now running the Suspend Services task, it will see that an invoice was past due at 10-4-2019 23:00:00 (an hour ago) and suspend it now instead of waiting until tomorrow (25 hours after due). 

i agree with this scenario .

Share this post


Link to post
Share on other sites

another episode of dates..... if date entered with format ('YYYY-MM-DD')  blesta make a strange date in database, i have tested this in two server with the same effect . so let see the case:

invoice A created today,
date billed : 2019-04-12  ==> saved in database with format 2019-04-12 23:00:00
Date Due: 2019-04-12  ==> saved in database with format 2019-04-12 23:00:00

invoice B created today,
date billed : 2019-04-12  ==> saved in database with format 2019-04-12 23:00:00
Date Due: 2019-05-12  ==> saved in database with format 2019-05-12 00:00:00

invoice C created today,
date billed : 2019-05-12  ==> saved in database with format 2019-05-12 00:00:00
Date Due: 2019-05-12  ==> saved in database with format 2019-05-12 00:00:00

invoice D created today,
date billed : 2019-05-01 ==> saved in database with format 2019-04-30 23:00:00
Date Due: 2019-05-02 ==> saved in database with format 2019-05-01 23:00:00

invoice E created today,
date billed : 2019-05-05 ==> saved in database with format 2019-05-04 23:00:00
Date Due: 2019-05-07 ==> saved in database with format 2019-05-07 00:00:00
 

what i ask why Blesta remove one hour from some dates?!!?!

 

Share this post


Link to post
Share on other sites

       $vars['date_added'] = 2019-05-01;

        print_r($vars['date_added'] . '<br />');
        print_r($this->dateToUtc($vars['date_added']) . '<br />');
        print_r($this->Date->cast($vars['date_added'], 'Y-m-d') . '<br />');
        print_r($this->Date->cast($vars['date_added'], 'Y-m-d H:i:s') . '<br />');

result

2019-05-01
2019-04-30 23:00:00
2019-05-01
2019-05-01 00:00:00

$vars['date_added']  = '2019-05-18';

result

2019-05-18
2019-05-18 00:00:00
2019-05-18
2019-05-18 00:00:00

 

just to note we use UTC timezone .

Share this post


Link to post
Share on other sites

I just tested that myself using the UTC timezone, and my system generates the dates as expected:

2019-05-01
2019-05-01 00:00:00
2019-05-01
2019-05-01 00:00:00


2019-05-18
2019-05-18 00:00:00
2019-05-18
2019-05-18 00:00:00

 

Under Settings > Company > General > Localization, is your company set to the timezone "(UTC +00:00) UTC", the option at the very bottom?

Your dates appear to behave as if your timezone crosses over daylight savings sometime between May 1 and May 18, which might be the case if you use a different timezone that varies between UTC +0 and UTC +1.

What do you get when you load the Date helper and format the time yourself?

Loader::loadHelpers($this, ['Date']);
$dates = ['2019-05-01', '2019-05-18'];

foreach ($dates as $date) {
	$this->Date->setTimezone(Configure::get('Blesta.company_timezone'), 'UTC');
	echo $date . ' to UTC: ' . $this->Date->format('Y-m-d H:i:s', $date) . "\n";
}

 

Share this post


Link to post
Share on other sites
16 hours ago, Tyson said:

I just tested that myself using the UTC timezone, and my system generates the dates as expected:


2019-05-01
2019-05-01 00:00:00
2019-05-01
2019-05-01 00:00:00


2019-05-18
2019-05-18 00:00:00
2019-05-18
2019-05-18 00:00:00

 

Under Settings > Company > General > Localization, is your company set to the timezone "(UTC +00:00) UTC", the option at the very bottom?

Your dates appear to behave as if your timezone crosses over daylight savings sometime between May 1 and May 18, which might be the case if you use a different timezone that varies between UTC +0 and UTC +1.

What do you get when you load the Date helper and format the time yourself?


Loader::loadHelpers($this, ['Date']);
$dates = ['2019-05-01', '2019-05-18'];

foreach ($dates as $date) {
	$this->Date->setTimezone(Configure::get('Blesta.company_timezone'), 'UTC');
	echo $date . ' to UTC: ' . $this->Date->format('Y-m-d H:i:s', $date) . "\n";
}

 

We use UTC+0 Casablanca, and yes it has a daylight saving time in RAMADAN month. the output are .

2019-05-01 to UTC: 2019-04-30 23:00:00
2019-05-18 to UTC: 2019-05-18 00:00:00 

so the saved date is correct, but still something is not logic, the saved date is not back to UTC when rendering it in backend, let say we have recorded a payment in 2019-05-01, when we search for payment from 2019-05-01 to 2019-05-02, the transaction is included in the search result, but in the cast date it show 2019-04-30, and it should be 2019-05-01 !! the Date class observe the daylight saving when saving date in database but is not observe it when formatting/casting date.

 

Share this post


Link to post
Share on other sites

tyson look here,

		$dates = ['2019-04-30 23:00:00', '2019-05-18'];

		foreach ($dates as $date) {
			$this->Date->setTimezone('UTC', Configure::get('Blesta.company_timezone'));
			echo $date . ' to custom UTC: ' . $this->Date->format('Y-m-d H:i:s', $date) . '<br />';
		}

we get expected result

2019-04-30 23:00:00 to custom UTC: 2019-05-01 00:00:00
2019-05-18 to custom UTC: 2019-05-18 00:00:00

in invoices/transactions the date saved in database with -1Hour, but it shown correctly in blesta as 2019-05-01, in our plugin the date is saved also with -1Hour but the cast function shown it as 2019-04-30 !!! what we are missing ?

Share this post


Link to post
Share on other sites

Where are you doing the date formatting at in your plugin? In a controller, a model, or somewhere else where you loaded the Date helper?

The Date helper maintains two timezones. The "from" timezone and the "to" timezone. When formatting a date, it will cast the date from the "from" timezone to the "to" timezone. you can set this with Date::setTimezones(from, to)

AppController loads the Date helper and sets the "from" timezone to UTC and the "to" timezone to the company timezone since it typically casts dates to the company timezone from UTC. (i.e. formatting a date will change the date from UTC to the company timezone when any child classes use the inherited $this->Date)

AppModel loads the Date helper but does not set the timezones. (i.e. formatting a date will change the date based on whatever the given date timezone is set to, or otherwise fall back to what the server timezone is set to)
AppModel::dateToUtc will convert a date from the company timezone to UTC. If you use the Date helper to format dates in a model that inherits from AppModel, you should set the "from" and "to" timezones accordingly.

Share this post


Link to post
Share on other sites

Yes, you should set the timezones after you load the Date helper. It will not set the timezones itself because it is not aware of the timezone of the dates you are working with or what you want to convert them to.

You could set the timezones on load (via the constructor), or via ::setTimezones.

Loader::loadHelpers($this, ['Date' => [null, 'Africa/Casablanca', 'UTC']]);

or

Loader::loadHelpers($this, ['Date']);
$this->Date->setTimezones('Africa/Casablanca', 'UTC');

Then, you can convert dates:

$this->Date->format('2019-05-01', 'Y-m-d H:i:s');

It's also useful to include timezone information in the date if it differs from the set timezones:

// Specify the date provided is in UTC
$this->Date->format('2019-05-01 00:00:00Z', 'Y-m-d H:i:s');

// Specify the date with the full timezone information for the current timestamp
$this->Date->format(date('c'), 'Y-m-d H:i:s');

 

Does setting the timezones fix the date issues you were having?

Share this post


Link to post
Share on other sites
2 hours ago, Tyson said:

Yes, you should set the timezones after you load the Date helper. It will not set the timezones itself because it is not aware of the timezone of the dates you are working with or what you want to convert them to.

You could set the timezones on load (via the constructor), or via ::setTimezones.


Loader::loadHelpers($this, ['Date' => [null, 'Africa/Casablanca', 'UTC']]);

or


Loader::loadHelpers($this, ['Date']);
$this->Date->setTimezones('Africa/Casablanca', 'UTC');

Then, you can convert dates:


$this->Date->format('2019-05-01', 'Y-m-d H:i:s');

It's also useful to include timezone information in the date if it differs from the set timezones:


// Specify the date provided is in UTC
$this->Date->format('2019-05-01 00:00:00Z', 'Y-m-d H:i:s');

// Specify the date with the full timezone information for the current timestamp
$this->Date->format(date('c'), 'Y-m-d H:i:s');

 

Does setting the timezones fix the date issues you were having?

yes, after we set the timezone the dates not appear correctly .

just a note the null return error, i have fixed by empty array

Loader::loadHelpers($this, ['Date' => [[], 'UTC', Configure::get('Blesta.company_timezone')]]);

Share this post


Link to post
Share on other sites
1 hour ago, Blesta Addons said:

yes, after we set the timezone the dates not appear correctly .

just a note the null return error, i have fixed by empty array


Loader::loadHelpers($this, ['Date' => [[], 'UTC', Configure::get('Blesta.company_timezone')]]);

Glad to hear it.

What error do you receive? null is a valid argument to Date::__construct:

public function __construct(array $formats = null, $timezone_from = null, $timezone_to = null)

 

Share this post


Link to post
Share on other sites
5 minutes ago, Tyson said:

Glad to hear it.

What error do you receive? null is a valid argument to Date::__construct:


public function __construct(array $formats = null, $timezone_from = null, $timezone_to = null)

 

Use of undefined constant null - assumed 'null' (this will throw an Error in a future version of PHP) on line 78 

 

Share this post


Link to post
Share on other sites

i have found the issue is not the null, it was a char before null that caused the error

        Loader::loadHelpers($this, ['Date' => [ null, 'UTC', Configure::get('Blesta.company_timezone')]]);
        Loader::loadHelpers($this, ['Date' => [null, 'UTC', Configure::get('Blesta.company_timezone')]]);

Share this post


Link to post
Share on other sites

That's strange. I don't encounter that issue when a space exists before null. Must be something with the context. I'm glad you were able to figure it out though.

Share this post


Link to post
Share on other sites
23 hours ago, Tyson said:

That's strange. I don't encounter that issue when a space exists before null. Must be something with the context. I'm glad you were able to figure it out though.

is not a space, is a strange char before null that is not visible and only can be detected by selection .

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

×
×
  • Create New...