Collection entry timestamps in CP lists are ignoring app timezone setting

joseph-d commented 2 years ago

Bug description

I created a new collection called Tests with a blueprint which contains a time-enabled date field called updated_at.

Creating an entry within this collection just now produces a timestamp of 1649151537 which is equal to 2022-04-05 09:38:57 UTC. In the collection list, this shows as 2022-04-05 09:38 as follows:

Screenshot_20220405_104237

However, because my config/app.php is set with 'timezone' => 'Europe/London', (which is UTC+1) I would expect this to show in the collection list as 2022-04-05 10:38

Indeed, running Carbon::now() outputs 2022-04-05 10:39:19.161282 Europe/London (+01:00) because it's taking the timezone setting in config/app.php into account and obviously a minute has passed since I wrote the above 2 paragraphs.

How to reproduce

Create this collection:

title: Tests
revisions: false
date_behavior:
  past: public
  future: private

Create this blueprint:

sections:
  main:
    display: Main
    fields:
      -
        handle: title
        field:
          type: text
          required: true
          validate:
            - required
      -
        handle: updated_at
        field:
          mode: single
          time_enabled: true
          time_seconds_enabled: false
          full_width: false
          inline: false
          columns: 1
          rows: 1
          display: 'Updated at'
          type: date
          icon: date
          listable: hidden
          instructions_position: above
          read_only: false
  sidebar:
    display: Sidebar
    fields:
      -
        handle: slug
        field:
          type: slug
          localizable: true
title: Tests

Create an entry in the collection by entering only the title and letting Statamic fill in the updated_at timestamp itself.
View the entry in the list, enabling the Updated at field using the Displayed Columns button
The time displayed under Updated at will be the server time (usually UTC) and will not be taking the Laravel config/app.php timezone setting into account.

Logs

No response

Versions

Statamic 3.3.4 Pro
Laravel 8.83.6
PHP 8.1.4

Installation

Existing Laravel app

Antlers Parser

runtime (new)

Additional details

As far as I'm aware, having the server set on UTC is standard practice so I do not believe I'm doing anything fancy.

jasonvarga commented 2 years ago

I notice that there is an inconsistency between the updated_at timestamp and regular date fields. Updated at is stored as UTC timestamp but date fields are stored as the timestamp in the defined timezone.

To fix this we'd need to be aware of both situations. To make them consistent, I think would be a breaking change.

What I would suggest in the mean time is perhaps to make a custom date fieldtype that extends our native one, use that for the updated_at field, and you could override the parseSaved method to ->setTimezone() appropriately.

joseph-d commented 2 years ago

Ahh, it looks like I opened this in April, a few days after we switched from UTC to BST here in the UK. Now it's the end of October so we're about to go back into UTC again which means I won't notice this issue for another 5 months. But at least now I have a plan for how I'll deal with it as April approaches next year - thanks!

jonassiewertsen commented 1 year ago

statamic / cms