Date Field does not store the picked date properly

[joernroeder]

Describe the bug

As reported by a client and replicated in a plainkit the date field does not save the selected value (on GMT+1) after updating to the latest version.

To Reproduce
Steps to reproduce the behavior:

1. Get the plainkit and modify the following files:

default.yml

title: Default Page
preset: page
fields:
  date:
    label: Date
    type: date
    default: today
  text:
    label: Text
    type: textarea
    size: large

home.txt

Title: Home

----

Date: 2020-02-21

----

Text: 

1. Go to the home page in the panel
2. The date field is prepopulated with the correct date 2020-02-21
3. Choose the 22th feb via the calendar on the right hand side of the date field
4. Open the inspector and save the page.
5. Inspect the params of the PATCH request (it send 2020-02-21T23:00:00.000Z in my case)
6. Confirm that home.txt is still stores 2020-02-21
7. Reload the page and the date field shows 2020-02-21 again

Expected behavior

the text file should store the selected date. 2020-02-22

Screenshots

Kirby Version
v3.3.3

PlainKit used plainkit-master-datefield-bug.zip

[afbora]

It looks very much like this issue #1813

I can't reproduce with your files as default. But i get this error only when the server time zone (GMT+2, saved 2020-02-21 23:00) is before/less my OS (may be browser)'s timezone (GMT+3, posted 2020-02-22 00:00). So it seems that this error occurs when the server and the user have different time zones 🤔

You can temporarily solve the issue using date_default_timezone_set()

@distantnative What do you think?

[joernroeder]

@afbora i was able to replicate it on localhost, served via php -S localhost:5555 with the plain kit in the zip file. would be interesting whats the default timezone for the php server and if it differs from the machine

[afbora]

@joernroeder Just wondering that does the error persist when setting the current time zone with date_default_timezone_set in your root index.php?

[joernroeder]

@afbora i can give it a try but whats also weird is that the PATCH request already sends the wrong date (2020-02-21T23:00:00.000Z) down the wire, strangely by the offset to GMT (+1) 🤔

[joernroeder]

@afbora changing index.php to the following does not change the PATCH request payload on save.

index.php

<?php

date_default_timezone_set('Europe/Berlin');

require 'kirby/bootstrap.php';

echo (new Kirby)->render();

Request Payload is still:

{"date":"2020-02-21T23:00:00.000Z","text":""}

[afbora]

@joernroeder Yes, the request is always doing by GMT+0. Still wrong date in txt file on date_default_timezone_set test?

[texnixe]

Interesting, I can reproduce it in the Kit you supplied, but not in a Starterkit.

[joernroeder]

@afbora @texnixe setting the timezone solved the issue for me and the date in the text file now corresponds to the selected one. (even tho it gets send as GMT+0)

[joernroeder]

@texnixe thats weird. I've downloaded it from the repo this morning. are you using the same server to serve the kits?

[texnixe]

Yes, I tested locally using Valet. Have to try and find what the difference is. I'll try again with both a fresh Starter- and Plainkit later.

[texnixe]

I don't know, it's really weird. Trying to understand under what circumstances this happens or not but don't really.

[yanickvw]

I noticed the same behaviour since version 3.3.3 (plain kit - MAMP). Setting the timezone in the index.php file solved the issue.

[joernroeder]

@yanickvw syncing timezones fixed it for me as well. but I am wondering what would happen I edit it from a different timezone 🤔

[afbora]

@distantnative @lukasbestle @bastianallgeier As I said in the other issue #1813, why don't we add a time zone option to the core like that?

return [
    'debug' => true,
    'timezone' => 'Europe/Istanbul',
];

public function setTimezone($timezone = null): void
{
    if ($timezone === true) {
        $timezone = ini_get('date.timezone');
    }

    if (empty($timezone) === false) {
        date_default_timezone_set($timezone);
    }
}

[afbora]

@texnixe I can reproduce only with different timezones not about default option for me.

[texnixe]

It seems to have been something else, not related to the default option. I haven't really found out yet why it works in the Starterkit but not in the Plainkit setup provided by @joernroeder .

[joernroeder]

@afbora why is it labeled as information missing? Is there anything I can do to push this further?

[afbora]

@joernroeder We were unable to fully reproduce the issue. I'm not really sure timezone issue. Were you able to look again? @texnixe

[joernroeder]

hm, as mentioned before, I was able to reproduce it in a plainkit downloaded from github and linked that above. I might clone the repo again, to see if i'm able to reproduce with 3.3.4. I still think there is some quirks behind, especially as the addition of a default timezone seems to fix it.

[afbora]

I suggested adding the timezone option to the core before, it would be nice. Even so @lukasbestle and @distantnative's thoughts can give us ideas about the issue and possible solutions.

[lukasbestle]

I think it would be nice to fix this in a way that doesn't require a manual timezone setting. After all the API request from the Panel contains the timezone and is therefore absolute, so the backend "only" needs to ensure that the value gets properly converted based on whatever the current server timezone is. That way it will work no matter if the server and client timezones match or not.

The other question is: Why did this break in 3.3.3?

[afbora]

Btw when i change timezone as Australia/Sydney (-660), date field seems like that for all (3.2.5, 3.3.0, 3.3.1, 3.3.2, 3.3.3) 🤔

Content

----

Date: 2018-10-11 00:15

----

[jonasfeige]

Running into the same issue on Kirby 3.3.4 using Laravel Valet. Currently in Lisbon (GMT+0). Setting the timezone in the index.php did not work for me, only when I manually change my machine’s timezone back to Berlin(GMT+1) does the date field work as expected.

[moevbiz]

I had the same issue. Setting the timezone in index.php to Europe/Berlin fixed it. I am in Austria, the website will be hosted on a server in France and the panel will be mostly used from Switzerland – let's see what's gonna happen… :~)

[Jayshua]

I am in Austria, the website will be hosted on a server in France and the panel will be mostly used from Switzerland – let's see what's gonna happen… :~)

This is why I generally discourage relying on the server's timezone. IMHO it should always be UTC. A few points:

• Not storing a timezone just means there is an implicit timezone. Sometimes that implicit timezone is specific (like storing the moment an event begins, that will always be the timezone the event occurs in), and sometimes the timezone is relative to some other entity. (like my birthday - it's always whatever timezone I happen to be in.) The key is that there always is a timezone, and it's basically never UTC.

• UTC offsets are not the same as timezones. I live in a timezone who's offset is -5. But in a few months when we stop observing daylight saving its offset will be -6. A qualified timezone from the tz database looks like this: Europe/Paris.

• Timezone shorthands are not timezones. In the US EST/CST/PST are common shorthands - but aren't precise and often encompass several distinct timezones that just happen to usually have the same UTC offset. Indiana for example actually has 9 distinct timezones, but most of them most of the time have the same UTC offset.

• Storing in UTC without timezones means you no longer know the timezone the date was selected for. Since timezones actually change fairly frequently you can end up having the date you stored be incorrect. (Just this year Yukon decided to stop observing daylight saving time, and Morocco moved their transition to daylight saving forward a week from Ramadan to the end of the month. If I remember correctly there were around 25 timezone changes in 2016.) Say I'm planning an event in Florida for October and Kirby stores the date in UTC. (Properly converting for the daylight saving transition of course.) Florida is considering whether to stop observing daylight saving. If that law is passed and Florida decides not to observe daylight saving this year, the start time of my event will now be off by 1 hour because the conversion to UTC was performed before the new rules were known.

• Just providing a timezone option in the config won't work for the reason above. If you actually perform the conversion to UTC for storage you've now lost information that will likely be necessary to continue displaying correct information. The most egregious example is when the tz/olson database (most commonly used timezone database for UTC conversion) isn't informed of jurisdictions changing their timezone rules until after those changes have occurred. In 2019 Palestine moved their daylight saving transition forward 7 days. The tz database wasn't aware of this change until one day after it had occurred. This means any dates converted to UTC during that time will now be off by 1 hour forever. To make matters worse the tz people were actually given the wrong date for the new transition, and so the database was still wrong until that was corrected.

Here's what I do/suggest kirby does

Store the date/time exactly as the user entered it without changes. This normally means always treating it as a string and never passing it to any date related functions or libraries since those usually try to do some timezone conversion. I never use Kirby's date picker for the reasons above, just a regular text input with a regex.

Always store the intended timezone as well. I always have this default to the panel editor's timezone, but I also let them change it if they need to. (That's usually important for my purposes because I deal with a lot of event planning in different timezones. Changing the timezone might be less important for other use cases, but storing it is still important to correctly handle changes to timezone rules.)

Usually there are only a few relevant timezones for my panel editors, so I give them a multiselect with a handful of pre-selected timezones to choose from rather than the entire 500+ list of all timezones.

Since Kirby sees translation and internationalization as important features, I think it should also have a correct and reliable way to deal with timezones and dates built-in. As far as I know this requires always storing the timezone along with the date, except when dealing with a date who's timezone is relative to some other entity. (Like my birthday.)

[plagasul]

I am having the same problem and had found the issue #2566 instead of this one, where I added some information. In that issue @hdodov interestingly points out that adding time: true to the date field solved the issue, may that be a hint to what this broke or how to fix it ?

I did not test with plain or starterkit, only with several websites on the same server. 3.3.1 does not seem to produce this problem in my case.

Setting the timezone in index.php 'solves' the issue in the sense that the server timezone becomes irrelevant, but not in the sense that accessing the panel from a different timezone to what is specified will still cause the issue, or so it seems from my tests.

[iskrisis]

Can confirm. This messed up live website after kirby update both valet and server. Editors figured it out and started to put one day more... and laughed at my incompetence.

Forcing timezone in index fixes it.

[SirNovi]

Same Issue on 3.4.0 locally with Valet. Agree with Jayshua "Store the date/time exactly as the user entered it without changes."

[bastianallgeier]

@distantnative is this still a problem with the new date field?

[distantnative]

If so it might be due to different reasons. I'm closing this everyone - please report and open a new issue if you see similar problems with the new date field.