You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sorry if this is a duplicate, but I couldn't find an existing issue when searching for some/all of "event date comma". I myself can't replicate that part of the issue—event dates with comma can be created fine-ish (read on) on my forum; I don't know what causes the error.
However, while testing this, I noticed the date strings are sometimes butchered, see below. (Maybe these are two separate issues and we should split them, but for now I suspect they are related.)
In the second, slightly older, forum with the german time_format, the dates are butchered and displayed as "%a.%d.%m.%Y, %H:%M" ("So.27.02.2022, 11:31 […] CET") instead of "%a., %d.%m.%Y, %H:%M" ("So., 27.02.2022, 11:31 […] CET"). For some reason, this doesn't happen in the nightly version forum with the default time_format ("Feb 27, 2022, 10:50 VORMITTAG […] CET").
Same thing with whole-day events:
alpha: "So.27.02.2022" (butchered)
nightly: "Feb 27, 2022" (fine, AFAICT)
In general, I get the feeling that time_format is used for both displaying dates in the forum (this is what the docs say), and programmatically working with the date, at least in the calendar context. I think this is a bad idea, for example I can imagine people even including static strings in the format string, like "year of the lord"-type stuff for religious forums, or "stardate" for other religions.
Steps to reproduce
Create an event
Notice the begin and/or end dates contain a comma (depending on time_format)
(Also notice the date strings are sometimes butchered (some commas and some spaces—apparently only in the date portion, not the time portion—have been removed))
Try to post the event
Some (users in some) forums will see an error, others won't.
Environment (complete as necessary)
Version/Git revision:
forum 1 ("nightly"): recent nightly tarball (2a2cac7(?)) with time_format "%b %d, %Y, %I:%M %p" (which might be the default),
forum 2 ("alpha", on the same server): 686a12c, with non-default time_format "%a., %d.%m.%Y, %H:%M"
The two most recent commits to #7336 should fix these issues: 9957ead should fix the mangled date strings when using multiple punctuation marks in a row. 4b17fcb works around the comma problem, which appears to be a bug in PHP's date_parse() function.
Description
Sorry if this is a duplicate, but I couldn't find an existing issue when searching for some/all of "event date comma". I myself can't replicate that part of the issue—event dates with comma can be created fine-ish (read on) on my forum; I don't know what causes the error.
Event creation error reported here:
However, while testing this, I noticed the date strings are sometimes butchered, see below. (Maybe these are two separate issues and we should split them, but for now I suspect they are related.)
In the second, slightly older, forum with the german
time_format
, the dates are butchered and displayed as "%a.%d.%m.%Y, %H:%M
" ("So.27.02.2022, 11:31 […] CET") instead of "%a., %d.%m.%Y, %H:%M
" ("So., 27.02.2022, 11:31 […] CET"). For some reason, this doesn't happen in the nightly version forum with the defaulttime_format
("Feb 27, 2022, 10:50 VORMITTAG […] CET").Same thing with whole-day events:
In general, I get the feeling that
time_format
is used for both displaying dates in the forum (this is what the docs say), and programmatically working with the date, at least in the calendar context. I think this is a bad idea, for example I can imagine people even including static strings in the format string, like "year of the lord"-type stuff for religious forums, or "stardate" for other religions.Steps to reproduce
time_format
)Environment (complete as necessary)
time_format
"%b %d, %Y, %I:%M %p
" (which might be the default),time_format
"%a., %d.%m.%Y, %H:%M
"Additional information/references
I don't think my locale plays a role in this:
The text was updated successfully, but these errors were encountered: