1) Create a site
3) Access dashboard
4) Setting the calendar to day n-1 is not permitted even though there is data generated for that day
If an "import piwik data" functionality would be developed later on, data older than the creation date of a site could be created. The same issue would occur.
Since the Site record is already loaded (i.e., avoid adding a new, potentially slow, query) and rather than deprecating this column, an alternative would be to add a method to change ts_created to reflect the earliest date for generated/imported data.
Wouldn't it be useful to leave untouched the ts_created field if one day the initial value is needed ?
It may be wise to keep the two concepts well separated. One date is the site administrative creation date within a particular instance of piwik (ts_created). The other date is the earliest known visit recorded for the website.
Not really, since getCreationDate() loses its meaning/intent/value if the database is populated with older data. In these cases, I suspect we have to add code to reprocess the archives.
agreed with vipsoft, it would be easier to update the ts_created time directly at the end of the visit generator process (less overhead, and the ts_created is not really useful if the user created fake visits anyway... as this is probably a fake/testing/temporary piwik website)
What implementation is preferred now?
Should the Visitor Generator:
ts_created cant be updated via API (not logical) so you can do it manually, or refactor in Core the following code from Integration->createWebsite
// Manually set the website creation date to a day earlier than the earliest day we record stats for Zend_Registry::get('db')->update(Piwik_Common::prefixTable("site"), array('ts_created' => Piwik_Date::factory($dateTime)->subDay(1)->getDatetime()), "idsite = $idSite" );
confusing and easy to fix, let's do it