Calender events with comma are sometimes truncated and sometimes can't be created

[m4z]

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:

• https://www.simplemachines.org/community/index.php?topic=578938.0
• https://www.simplemachines.org/community/index.php?topic=579402.0
• https://www.simplemachines.org/community/index.php?topic=580955.0

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

1. Create an event
2. Notice the begin and/or end dates contain a comma (depending on time_format)
3. (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))
4. Try to post the event
5. 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"
• Database Type: postgres
• Database Version: 9.6.something / any
• PHP Version: 7.0

Additional information/references

I don't think my locale plays a role in this:

$ locale
LANG=
LANGUAGE=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

[Sesquipedalian]

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.

Please test to confirm that it works for you.

[Sesquipedalian]

Please test to confirm that #7336 fixes this issue.

[m4z]

Yep, looks good. Thanks!