Does anyone else has this issue? When I use a date field without time and save, it saves has the nest day not the one I selected. If I use time, it saves the right date.
I can’t reproduce that. Could you please provide more information? Your Kirby version, your blueprint setup, single or multi-language?
I’m upgrading from kirby 2 to kirby 3, it’s single language. Kirby 3.0.2
Blueprint:
columns:
- width: 2/3
fields:
datetimestart:
label: Inicia
type: date
time: false
What timezone are you in? I remember conversion issues from a project where timezones became a problem with dates moving to other days in GMT.
I’m at GTM -7. Is there any steps I should take on configuration?
What timezone is the server set to, then?
I just download and tested the starterkit with a Local server with MAMP. I went into the blurprints for “note”, changed the time property for date as time: false and changed the date to today.
On the panel you can see the right date, but on the note page you get the next day.
I think this is a pure JavaScript issue that needs to be handled before sending to the server.
When I remember correctly JavaScript adjusts the time based on the timezone when converting to GMT. Stripping the timezone might help.
I don’t know much about servers but on local MAMP a have no set time zone, tested on a real server date.timezone is UTC
Do you have a time zone set in your php.ini?
Seems like my issue it is the wrong timezone in php.ini, I finally found how to change it on MAMP. But I’m having some issues with my server today. Hopefully it gets fixed soon so I can confirm.
Thank you for the help, I don’t now much about servers.
I too am having this exact same issue - can’t seem to figure it out. Driving me crazy.
Date is saving properly in the event page within panel - but is displaying 1 day ahead on site and in event list in panel.
Looks like you already found the GitHub issue: https://github.com/getkirby/kirby/issues/1813#issuecomment-564275246?
The Github issue has been closed but the issue still exists for me. Running on Kirby 3.3.4.
You can see that the day decreases when I hit save. It only occurs on certain day/month combinations. While it does for example happen when I try to save a date in May, it does not seem to happen in February. Any ideas?
2020 is a leap year. Might that be a problem?
Same thing happens for 2019. It’s really strange …
I am going crazy here … I have tried pretty much everything suggested in this thread, but nothing has helped so far. In addition to the days being changed on save, I also have a sorting issue I cannot figure out.
This pages section is set to sortBy: date asc but as you can see the sorting does not really work. I have converted the dates to timestamps (see the third column) to see if they are correct and it seems they are. I have even put these into Numbers/Excel and sorted them there – works as expected.
I am using the k3-date-format plugin but have also tried it without, same story. Any help is greatly appreciated!
I’m afraid I have to chime in here. When saving a date the field saves the previous day instead. Tested this on a 1&1/ionos server with a copy of the actual client’s website (kirby 3.3.5) and the starterkit (kirby 3.3.6), running on PHP 7.3.17 and 7.4.5. Now for the fun part: Saving this on my local mamp running on PHP 7.3.9 and 7.4.2 all works like it’s supposed to. Also changed my mac’s time to before february 2020 with no effect.
edit: found the behaviour in this issue on GitHub: https://github.com/getkirby/kirby/issues/2416
Ah! I just opened a similar thread and this other issue is referenced in it
So it seems this issue has been around since v3.3.3 and has not been solved 
as it could not be fully reproduced? well that kinda sucks.
Hristiyan Dodov says adding time: true to the field eliminates this problem, may be a good workaround depending on the case.
@tojai Additionally as explained in the issue you linked setting the timezone in index.php to match the timezone of the machine used to access the panel also fixes this. If all users belong to the same timezone that would be enough to fix this for them.
1 Like
just saw your reply. right, in this case it fortunately works. though i have other projects where i might hit a wall with this. will keep an eye on it and report.