Essentially,
Saturday at 2:50 PM -> Saturday at 4:38 PM becomes
Saturday at 2:50 PM -> 4:38 PM (Singapore)
Also, the displayed dates are shortened when the standalone date
is within two days. So despite the 'from' and 'to' date being the
same day, it may show 'Saturday' for 'from', and the specific date
for the 'to'. This corrects the behaviour.
(so if the current date and time is Thursday 5PM, the 'from' date
below is within 2 days, but the 'to' date is not)
Saturday at 2:50 PM -> 8 October 2022 at 9:38 PM becomes
Saturday at 2:50 PM -> 9:38 PM
This commit allows quoting of discourse-local-date elements
and converts the quoted tags back into bbcode so that the
rendered quote will also render the discourse-local-date HTML.
This works on single dates as well as date ranges, and supports
all of the options used by discourse-local-date.
This also necessitated adding addTextDecorateCallback to the
to-markdown core lib (similar to addBlockDecorateCallback and
addTagDecorateCallback) to transform the text nodes between
date ranges to remove the -> in the final quote.
c.f. https://meta.discourse.org/t/quotes-that-contain-date-time/101999
New range tag for local dates with syntax like:
```
[date-range from=2022-01-06T13:00 to=2022-01-08 timezone=Australia/Sydney]
```
Previously, 2 dates in one line were considered as range. It was hard to decide if 2 dates are range when they were in separate lines or have some content between them.
New explicit tag should clearly distinguish between single date and range.
Common code from `addLocalDate` is extracted to `addSingleLocalDate`.
Both `addLocalDate` and new `addLocalRange` are using `addSingleLocalDate`.
Also, `defaultDateConfig` was extracted to have one place for all possible parameters.
This PR is introducing 2 changes.
1. Date popup is displayed on click instead on hover
2. If the range is given then the whole range is always displayed for both startDate and endDate
3. For range, short time is displayed for end if the range is < 24 hours
- prefers insertAdjacentHTML over innerHTML as it's much faster in this case (about 5x)
- memoizes tz.guess()
- memoizes list of timezones
- inlines template
- applies main element class in one pass
All in all for a very edge case of about 80 dates it should be faster of about 15/20ms.
Over the years we accrued many spelling mistakes in the code base.
This PR attempts to fix spelling mistakes and typos in all areas of the code that are extremely safe to change
- comments
- test descriptions
- other low risk areas
You might wonder why this matters. It turns out in some locales like
French, we replace quotation marks with « and » -- this should likely
not happen before BBCode is parsed but that is not the case for this
plugin. The plugin has code to handle this situation, but it means extra
spaces are inserted around the time zone which breaks it.
This fix allows us to supply extra whitespace and will show the correct
time zone.
eg:
timezone="America/Detroit"
timezones="US/Eastern"
Before this commit we would show America/Detroit in previews and not US/Eastern, given US/Eastern and America/Detroit are equivalent.
After this commit, we will display the date with America/Detroit but show US/Eastern in the previews.
