The smart date formatter is available for use with the core date field type. Those values are stored in the YYYY-MM-DDTHH:MM:SS format. When passing through `\Drupal\smart_date\SmartDateTrait::augmentOutput` the code assumes start_ts and end_ts are unix timestamps and pass it through to DrupalDateTime::createFromTimestamp which causes it to fail the is_numeric check.
- Create a date field (not smart date)
- Assign the smart date formatter
- Use Date Augmenter to trigger \Drupal\smart_date\SmartDateTrait::augmentOutput
Add is_numeric() checks in augmentOutput for $start_ts and $end_ts and convert strtotime() if they exist.
I assume $end_ts should equal $start_ts if it is null?
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
joewhitsittComment #5
mandclu commentedThanks for identifying this, and for suggesting a fix. The approach you've taken seems sensible enough, but I wonder if it wouldn't be better to update the call to augmentOutput() within SmartDateTrait::viewElements to pass in the calculated $start_ts and $end_ts values instead (or maybe in addition?).
The original code looks like it did that, which makes me think there's a reason I decided not when this was refactored. A year later, however, I don't seem to have any notes on that.
I'm inclined to want to test that first, to see if there's an obvious reason why using the $start_ts and $end_ts values already calculated wouldn't be a better approach.
Comment #7
mandclu commentedAfter giving this some more thought, it only makes sense to ensure the values are numeric without the augmentOutput method, whether or not the method should be fed the original, unaltered values. I added a todo to revisit that question, and also moved the code that normalizes the values before the loop. Merged in.