V8-archive: Activity datetime is incorrect

[benhaynes]

If you save an item (eg: on the demo), the activity is saying 4 hours ago... which is incorrect. This has been an issue in the past, it needs to be resolved completely this time.

[benhaynes]

Also, when adjusting this, is it possible to shorten the contextual time by removing about?

[diegofreemind]

@benhaynes i gonna take a look on it.

[benhaynes]

Thanks @diegofreemind — good luck and let us know how it goes! :)

[bjgajjar]

It's an API issue. The data stored in DB in the provided timezone of the configuration file. But for the response, it's converted into UTC timezone. Thus, transferring it into API repo.

[bjgajjar]

Fixed in https://github.com/directus/api/pull/1430

[jacobrienstra]

unfortunately this is still a problem for the created on fields

but i think it's an app issue. the UI takes the time from the server and uses string.replace and assumes it's GMT

[benhaynes]

I can also confirm this is not working correctly. I have the default created_on and modified_on fields... and they are not saving the correct time.

[bjgajjar]

@benhaynes - API storing [At that timezone which is configured in project config file] as well as returning the correct data. But APP is converting it into GMT. So for the further changes, it seems like we should move this to APP as the API is the culprit for time ago issue but this date-created issue is related to APP.

[benhaynes]

That doesn't make sense — these use the datetime_created TYPE, not datetime. So the API should be setting these values... not accepting them from the App. What if you save an item directly in the API? We should still be setting the created/modified dates... so these need to be API only.

[bjgajjar]

I think you are not getting my point - let me provide you the screen recording. System timezone is Asia/Kolkata and trying to add an entry at 2019-11-19 01:05:10 which is stored in DB too. But the APP shows it as Tue, Nov 19, 2019, 6:35 AM GMT

[benhaynes]

I just saved an item that has a date_modified. It saved in the database as 2019-11-18 14:52:26 but the current GMT/UTC is 2019-11-18 19:52:26.

The App shows it as Mon, Nov 18, 2019, 9:52 AM GMT ... so the App _would_ be showing it correctly if the API saved the correct value.

[bjgajjar]

After PR https://github.com/directus/api/pull/1197 - API will store the time based on the project configuration timezone and not in the GMT / UTC.

[benhaynes]

I'm sorry, but now I am really confused. You're moving _away_ from GMT/UTC? That's the opposite of what we want, right? We want to store all system times in GMT/UTC. Nothing in the system fields should be specific to your server's timezone.

@rijkvanzanten am I correct... or am I confused? 😕

[rijkvanzanten]

Everything that the API saves to the database that is not user generated content (like date created, date updated, activity, login, etc) should be in UTC

[everyx]

Hi, can we store all datetime reference fields as UTC time, so that we have a single one datetime standard, and API will only return UTC time for APP and any other request to API, let the client handle the localized display of time.

the APP should send datetime with timezone info or a UTC time directly to API, so that API can get the correct UTC time to store into database.

[bjgajjar]

We want to store all system times in GMT/UTC.

Okay but then may I know what's the use of app.timezone from project configuration file?

IMHO, the system generated content should be in that timezone which is configured in the project configuration file. So the user can get the desired response based on their requirements.

Currently, America/New_York is default timezone - we can replace it with UTC. So if the user will not update it; the result will be in UTC format.

[rijkvanzanten]

@bjgajjar no one configures that manually, there's a bunch of stuff that doesn't use projects for time (auth, project create, etc), and like @everyx correctly said: we should have a single time standard for all requests.

[codedefective]

I solved the problem by typing hook. my problem was related to the created_on column.
`return [

  'filters' => [
    'item.update:before' => function (\Directus\Hook\Payload $payload) {
        if ($payload->has('created_on')) {
            $date = date_create($payload->get('created_on'));
            $payload->set('created_on', date_format($date, 'Y-m-d H:i:s'));
            //$payload->remove('created_on');  // You can also use this method if you want to remove the column from payload instead of updating it.
        }
        return $payload;
    }
  ]

`