[Panel] Option for `date` field to store values in UTC

[hdodov]

We had a discussion in Slack regarding timezones and calculating relative time.

The gist of it was that I wanted to display how much time has passed since a stored date in Kirby. I thought I had to take the site visitor's timezone into account, but I don't. As I said in Slack:

Time passes at the same speed in all timezones, so it's irrelevant in what timezone the user is as long as you're comparing two timestamps from the same timezone.

For example, I store a date in UTC in Kirby and when the user loads the page, I compare that date with the server's current time, which is also UTC. So if 15 seconds have passed, the users sees "15 seconds ago." The fact that I'm in UTC+2, for example, was irrelevant in this whole calculation.

There would have been a problem if that date was entered by me because I would have entered it according to my own time, which is in UTC+2, and then it would have been compared to the server's understanding of now, which is in UTC. Then, I'd be off by 2 hours.

So the timezone doesn't matter as long as it's the same, which could be a problem if there are multiple editors changing a single date. You might point me to the PHP docs for time formats where there's the RFC 2822 r format:

Mon, 23 Mar 2020 07:30:00 +0100

That +0100 part is the timezone indeed, but the server's timezone, which is basically useless. If there are two editors in two different timezones, the dates they save will be in the server's timezone, which would always be the same.

Example

Let's say we have Cho from Seoul (UTC+9) and Emma from Berlin (UTC+1). They both create a page at March 23-rd, 14:00 UTC by looking at their clocks and entering that date and time in the Kirby Panel. That date is stored in the r format mentioned above.

• The clock in Cho's house shows 14:00 + 9 hours = 23:00, so he selects Mar 23 23:00
• The clock in Emma's house shows 14:00 + 1 hour = 15:00, so she selects Mar 23 15:00

However, the server is in New York (UTC-4) and it stores the following dates:

Mon, 23 Mar 2020 23:00:00 -0400
Mon, 23 Mar 2020 15:00:00 -0400

...and this is where the problem comes - the dates are stored as if both were entered in the server's timezone, UTC-4, instead of UTC+9 and UTC+1, respectively. Then, if you were to compare the two dates in PHP, you'd get an 8 hour difference for times that were entered simultaneously.

No matter what format you use to store the dates, there would always be a difference. If you use the default format, you'd still get:

2020-03-23 23:00
2020-03-23 15:00

Proposal

The date field could have a new utc option that, when set to true, will make the panel app convert the user's input to and from UTC.

Currently, if Cho saves Mar 23 23:00 in the Kirby panel, it would send over the following string to the Kirby API:

2020-03-23T23:00:00

...then Kirby uses its own timestamp() helper, which in turn uses strtotime() to parse the input.

If utc: true is set, the panel app could use Date.prototype.toISOString() to convert Cho's date to this instead:

2020-03-23T14:00:00.000Z

...and store it as 2020-03-23 14:00, for example.

---

Later, Cho opens the panel again and apparently, Kirby would send the date in this format:

2020-03-23 14:00:00

...and Cho would see Mar 23 14:00 even though he entered Mar 23 23:00? Yes, but JavaScript can parse that date as UTC and convert it to Cho's timezone if it ends with Z:

new Date('2020-03-23 14:00:00')  // Mon Mar 23 2020 14:00:00 GMT+0900
new Date('2020-03-23 14:00:00Z') // Mon Mar 23 2020 23:00:00 GMT+0900

So to make that work, this line should be changed to append a Z if utc: true.

Example 2

If this fix is applied and Cho and Emma use that same date field but with utc: true:

1. Cho enters Mar 23 23:00 (UTC+9), Emma enters Mar 23 15:00 (UTC+1)
2. Kirby uses toISOString() and saves 2020-03-23 14:00 for both Cho and Emma
3. Both of them reopen their pages and Kirby returns 2020-03-23 14:00Z to both of them
4. The panel app parses the dates and returns Mar 23 23:00 for Cho and Mar 23 15:00 for Emma

Even if someone else in a completely different timezone comes, he would see that time in his own timezone, but save it in UTC. This would synchronize the dates between editors. Otherwise, if Cho visits Emma's page, he'd see 15:00, and if Emma visits Cho's page, she'd see 23:00, when in fact they entered the same date.

[lukasbestle]

I like the idea! However I think the option should be called something like userTime.

[hdodov]

@lukasbestle it depends on your point of view. If you're in the panel, it's your local (user) time, yes. But from the perspective of Kirby, it's UTC. I called it utc because that's what's actually stored and if you're looking at the content files, you'd be less surprised to find the dates there are completely different from those entered in the panel, i.e. userTime. Since the editor isn't bothered with that option name, it should be more intuitive for the developer?

The option could also be called coordinated or sync because it synchronizes the various editors.

[nilshoerrmann]

Strong vote for utc because this correctly labels the date while userTime could be anything.

[bastianallgeier]

I have to say that I'm also for utc as option name.

[lukasbestle]

You are right! If we look at it from the perspective of what gets stored, utc makes sense.