weird display of date

[papillon-unix]

Hello

I'm new to Pico, working on a website with it and I got to love this ultra-light cms very quickly.

Since I need PHP 8 for other needs I run the 3.0.0-alpha.2

Everything works fine except one very annoying thing :

When a YAML file contains a date, for example :

date: 2024-05-05 18:30:00

And when I tried to display it in a template, whether with a date filter or not :

{{ post.date|date("m/d/Y H:i") }} or {{ post.date }}

it returns an UTC time instead of the right time of my timezone. In this case it will display:

2024-05-05 20:30:00 instead of 2024-05-05 18:30:00

I checked that my config is set to Europe/Paris and when I tried to display {{ "now"|date("m/d/Y H:i") }} it returns the correct time.

I searched for hours a solution to this problem and couldn't find it.

So I had to patch my template with something like {% set adjustedDate = post.date|date_modify('-2 hours') %} to get the correct time.

Any idea where does it come from?

Besides, so sad that PicoCMS is abandonned. I tried many flat file cms and this one is really the lightest and the best for my needs.

Thanks a lot if anyone reads me.

[PhrozenByte]

Check the timezone config in Pico's config.yml. Also note that page.date already contains a date string; use page.time to access the timestamp, or page.date_formatted to print the formatted date according to the date_format config in Pico's config.yml.

[papillon-unix]

Thanks a lot for the answer.

I did put the timezone in config.yml

I can't really use date_formatted because I want to format differently under different situations.

I doesn't work any better with page.time - I still get a date convert to UTC instead of the actual value of date written in the file..

[PhrozenByte]

The timezone config in config.yml tells Pico to call PHP's date_default_timezone_set(), which in turn tells PHP the default timezone to use with date(). So it can't be an issue with date() (i.e. the output), but with the input.

Pico doesn't parse the date header on its own, but simply uses the value provided by Symfony YAML, the YAML parser Pico uses. So I just checked and the YAML specs apparently specify that a date string must be interpreted as UTC if no timezone is given. I assume that Symfony YAML just follows the specs here and therefore interprets your date string as UTC.

Thus, please try adding a timezone to your YAML headers, like:

date: 2024-05-05 18:30:00+02:00

[PhrozenByte]

I assume this to be pretty unexpected. We should probably overrule the YAML specs here and use the timezone config in config.yml instead - if this is even possible (see below). Thus changing this to a upstream bug. However, please don't expect a fix in the near future (if ever, as you know, Pico's development has stopped).

A few notes for a possible future fix: The current Symfony YAML version returns just a timestamp (timezone-independent by design), but newer Symfony YAML releases allow returning a DateTime instance using some parser flag. However, it might still be impossible to safely distinguish between a DateTime instance that used UTC as fallback, or a user specifically telling the timezone to be UTC (e.g. 2024-05-05 18:30:00Z). There's currently no option in Symfony YAML to change the default timezone; we could propose an upstream patch, but since the YAML specs seem to be pretty clear about the matter, I'm not so sure whether they would accept such patch. So, in the end, I'm not sure whether we can fix it. If not, we should at least document it...

[papillon-unix]

Thank you so much. Following your suggestion, I added the timezone directly to the YAML headers, and it works perfectly. Your explanations are very clear. I was initially confused because I had previously used the CMS Stacey, where such specification wasn't necessary. I switched to Pico due to the PHP 8 compatibility of its fork. Once again, thank you. I'll stick with my template-side fix.

I've heard that Pico has been sold and that the new owner isn't responding to commits. Is that correct? Is it possible that they acquired it with the intention to shut it down?

[PhrozenByte]

Let's keep this open since it's a unfixed bug 👍

I've heard that Pico has been sold and that the new owner isn't responding to commits. Is that correct? Is it possible that they acquired it with the intention to shut it down?

Gilbert, the original author, sold the project a very long time ago to Greg, the current owner. AFAIK Greg is no PHP developer, he just owns the project. I took over development some years ago and basically rewrote it from scratch while keeping Gilbert's base concept, mostly because I was using it myself. However, I no longer have the time (nor will tbh...) to work on Pico. I still provide some basic support for the remaining users though...

Since nobody else wanted to take over responsibility yet, Pico is basically abandoned from a development perspective. However, I believe that if someone wants to take responsibility, one could still get write access, just as I did years ago. I'm not aware of any plans to shut it down.

[dkyme]

TLDR: to keep your Date in your Timezone put it in Brackets, to be parsed as String not as DateTime in UTC.

The YML parsing works according to the Specs.
The Timezone is always UTC and if you need to keep your Date within your Timezone without specifing it, use Strings:
Date: "2024-07-14 12:00:00" will be parsed and keep the Timezone in Pico or your Plugin, while:
Date: 2024-07-14 12:00:00 will be parsed as UTC Timezone.

The YAML Specs ( Example: 2.22) allow following input:
canonical: 2001-12-15T02:59:43.1Z
iso8601: 2001-12-14t21:59:43.10-05:00
spaced: 2001-12-14 21:59:43.10 -5
date: 2002-12-14

Source: #https://yaml.org/spec/1.2.2/

See also the Discussion in: symfony/symfony#26607 (comment)

So, it's not a Bug, it's a feature ;-)

[papillon-unix]

THANK YOU SO MUCH
It was as simple as that but I could never find it by myself, it works perfectly.
Much much appreciated