Kirby Dates and Timezones

Maybe related to these: Kirby messes with "time", Date-field doesn't save local time

I think this is a bug. It looks very bug-like - lots of little legs. But it’s kinda confusing so maybe I’m just doing something wrong.

Here’s what happens when I use the Date field in my blueprint:

  • The user picks a date and saves. Let’s say 2019-08-29
  • Prior to sending it to the server the browser converts it to UTC time. It assumes you meant midnight on whatever day you picked, then subtracts the timezone offset. So if you are in a -5 timezone like me, it sends 2019-08-29T05:00:00.00Z to the server. (Note that in my case the timezone offset is negative, so the result of subtracting it increases the time.)
  • The server accepts the offset date, truncates the timestamp portion and saves it to the .txt file.
  • Later the server reads the .txt file, assumes UTC timezone, attaches a midnight time, and sends it off to the browser like this: 2019-08-29T00:00:00.00+00:00
  • The browser accepts the date, notices that it is in UTC time and adds the local timezone offset. In my case -5, which converts the date to 2019-08-28T19:00:00.00
  • The date field does not display the time portion, only showing 2019-08-28 to the user when they originally entered 2019-08-29

The topics I linked above suggest setting PHP’s timezone. Correct me if I’m wrong, but I don’t think that will work if users are in multiple timezones.

There’s an issue on GitHub: https://github.com/getkirby/kirby/issues/1813

Handling dates is hard. Some browsers base date times from what the operating system is set to (from memory, internet explorer and safari both do this, since the come with the operating system).

I once spent days trying to get internet explorer to give me a date back in UK format, rather then US. This was down to operating system locale despite being in the UK. This might be part of the problem.

As @texnixe its on the radar, so hopefully you will see a patch soon :slight_smile:

Just out of interest, if use Firefox or Chrome, and properly set the date / time zone in the browsers preferences (most software default to US in the absence of being told otherwise), does the issue persist? That could be a work around in the meantime.

I observed this behavior personally in Firefox with -5 zone and it was reported to me by a user using Chrome. No idea what their timezone preferences were set to, but probably -6:00.

My temporary fix is to change the date(W3C_TIME, $timestamp) line in the date field php file to date('Y-m-d', $timestamp) - this prevents it from attaching the UTC timezone and the browser assumes local time.

Thanks @texnixe, I didn’t notice that issue!