View Single Post
Old 08-10-2020, 12:14 PM   #494
thiago.eec
Wizard
thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.
 
Posts: 1,234
Karma: 1419583
Join Date: Dec 2016
Location: Goiânia - Brazil
Device: iPad, Kindle Paperwhite, Kindle Oasis
Quote:
Originally Posted by capink View Post
This is interesting, because the link talks about this problem occurring in pubdate. In My testing, populating pupdate did not cause this problem. When I looked at the code to see why, I found that field_from_string was not used when populating pubdate, instead it calls parse_date (through a function called parse_pubdate).

So maybe someone fixed this for pubdate but did not do the same for custom date columns.
When I was working on Skoob Books plugin (Jun. 2019), I've noticed this.

Skoob website only give us the year of publication, so I chose to set the pubdate to YYYY-01-01, but this made dates to be set as (YYYY-1)-12-31. As a workaround I chose to set it as YYYY-01-02. Since the real date was only the Year, this would make no difference.

Now, I've just checked and setting pubdate as YYYY-01-01 works normally. It must have been fixed in this interval.
thiago.eec is online now   Reply With Quote