##### Re: Datetime problems with Publisher 1.07 Final and Xoops 2.5.10
• 2020/4/21 23:11

• Moderator

• Posts: 11209

• Since: 2004/4/23

Thanks Lucio!!!!

Lupin, can you test if this solutions works for you? If it does, we'll add it to Publisher.
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

##### Re: Datetime problems with Publisher 1.07 Final and Xoops 2.5.10
• 2020/4/21 23:18

• Moderator

• Posts: 11209

• Since: 2004/4/23

Lupin, can you test also the Yogurt and let us know if the dates there are presented correctly for you?

Since it is now in development, it's a perfect opportunity to make sure that it works shows the dates properly

Thanks!
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

##### Re: Datetime problems with Publisher 1.07 Final and Xoops 2.5.10
• 2020/4/22 10:08

• Moderator

• Posts: 11209

• Since: 2004/4/23

Lucio, I think, this is the same issue that Mage was talking about in the Core post. See Richard's response:

https://github.com/XOOPS/XoopsCore25/i ... 07#issuecomment-614837189
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

##### Re: Datetime problems with Publisher 1.07 Final and Xoops 2.5.10
• 2020/4/22 11:48

• Just popping in

• Posts: 92

• Since: 2007/6/1 2

@ Lucio & Mamba : of course I will test this solution.

@Mamba : if you give me some little time , I will install Yogurt in my "parallel" installation and I will report you

@Lucio : ... no way to see xoops.it coming back ?

##### Re: Datetime problems with Publisher 1.07 Final and Xoops 2.5.10
• 2020/4/22 12:23

• Module Developer

• Posts: 211

• Since: 2007/4/20

I know

##### Re: Datetime problems with Publisher 1.07 Final and Xoops 2.5.10
• 2020/4/22 13:28

• Just popping in

• Posts: 92

• Since: 2007/6/1 2

I see this :

None All Errors (2) Deprecated (0) Queries (18) Blocks (0) Extra (3) Timers(3)
Errors
Notice: Array to string conversion in file /class/libraries/vendor/xoops/xmf/src/FilterInput.php line 251

Anyway it seems with the format d-m-Y instead of d/m/Y it works better. ( done before your hack )

##### Re: Datetime problems with Publisher 1.07 Final and Xoops 2.5.10
• 2020/4/22 15:40

• Just popping in

• Posts: 92

• Since: 2007/6/1 2

Since in Yogurt module there are no datetime settings, with correct timezone both in System preferences and in user preferences , time is perfect.

Dates seemed to have different formats depending from which modules they were taken , of course "american style" ( Y/m/d or ) , then I modified global.php with

 define('_DATESTRING', 'd/m/Y H:i:s'); define('_MEDIUMDATESTRING', 'd/m/Y H:i'); define('_SHORTDATESTRING', 'd/m/Y'); 

and in IMO everything works well in "european style".

This was a quick look, but if you want I can see more ...

##### Re: Datetime problems with Publisher 1.07 Final and Xoops 2.5.10
• 2020/4/22 19:56

• Module Developer

• Posts: 211

• Since: 2007/4/20

Try again ... Xoops using "\DateTime" and not "DateTime"
Quote:

luciorota wrote:
The bug is the result of an incorrect use of the function strtotime(), it must have a format in English to work...

BUGFIX

file: publisher\class\item.php, line 1061
replace
 $localTimestamp = strtotime($resDate['date']) + $resTime['time'];  with $dateTimeObj = \DateTime::createFromFormat(_SHORTDATESTRING, $resDate['date']);$dateTimeObj->setTime(0, 0, 0); $localTimestamp =$dateTimeObj->getTimestamp() + $resTime['time'];  file: publisher\class\item.php, line 1088 replace $localTimestamp = strtotime($resExDate['date']) +$resExTime['time']; 

with
 $dateTimeObj = \DateTime::createFromFormat(_SHORTDATESTRING,$resExDate['date']); $dateTimeObj->setTime(0, 0, 0);$localTimestamp = $dateTimeObj->getTimestamp() +$resExTime['time']; 

Good job! / Buon lavoro!

##### Re: Datetime problems with Publisher 1.07 Final and Xoops 2.5.10
• 2020/4/23 11:47

• Just popping in

• Posts: 92

• Since: 2007/6/1 2

OK Lucio & Mamba,

it seems that the modification also works with the d/m/Y format ... I think you can use this mod.

However, there are a couple of aspects to review:

the first concerns the date that the system proposes in the date field of the item modification form; in fact this proposes today's date instead of proposing the one that had previously been inserted. In addition to the problem of having to always check this data with each modification of other parts of the article, there is the danger that clicking "back" on the web bar, wrong data will be sent and you will find yourself with the article with today's date. The system should be able to interpret whether it is a new sending request or an article change request.

The second problem is always that of the time ... although the time zone is set to GMT + 1 both in the general preferences and in the user account data, there are two hours of difference in the time displayed. In practice, if the sending time is set at 13.00, the 11.00 time is then displayed.

Cya

Pino

Update :

about the first problem , I saw if I set :

 define('_DATESTRING', 'd-m-Y H:i:s');  define('_MEDIUMDATESTRING', 'd-m-Y H:i');  define('_SHORTDATESTRING', 'd-m-Y'); 

The form propones the correct stored data

if I set :

 define('_DATESTRING', 'd/m/Y H:i:s');  define('_MEDIUMDATESTRING', 'd/m/Y H:i');  define('_SHORTDATESTRING', 'd/m/Y'); 

The form propones the today's data ... it is possible?

### Recent Posts

• ##### Re: XoopsCore25-2.5.11-Beta1 On PHP Version 8.0.13 protector some error,get_magic_quotes_gpc() returns undefined
Yesterday 16:20 Mamba

### Who's Online

79 user(s) are online (50 user(s) are browsing Support Forums)

Members: 0

Guests: 79

### Donat-O-Meter

 Stats Goal: $100.00 Due Date: Dec 31 Gross Amount:$0.00 Net Balance: $0.00 Left to go:$100.00

### Latest GitHub Commits

• ##### {{ record.sha.slice(0, 7) }} - {{ record.commit.message | truncate }}
{{ record.commit.author.name }} {{ record.commit.author.date | formatDate }}