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:

• send a plain SQL-Query to the database and change ts_created?
• call a new API method (or: updateSite(.., ts_created = '') ) to update ts_created?

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

(In [3660]) Fixes #1373