Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docs for most public functions for formatting DateTimes and Numbers #73

Merged
merged 6 commits into from
Apr 8, 2023

Conversation

ntwilson
Copy link
Contributor

@ntwilson ntwilson commented Jul 4, 2021

Description of the change
This PR just adds documentation for most of the existing public functions in the Data.Formatter.DateTime and Data.Formatter.Number modules. Intended to help with #60, though I don't know if it's fair to say it fixes it. I aired on the verbose side, so let me know if I need to do some pruning.


Checklist:

  • Added the change to the changelog's "Unreleased" section with a link to this PR and your username
  • Linked any existing issues or proposals that this pull request should close
  • Updated or added relevant documentation in the README and/or documentation directory
  • Added a test for the contribution (if applicable)

@ntwilson ntwilson marked this pull request as ready for review July 4, 2021 03:13
format ∷ Formatter → DT.DateTime → String
format f d = foldMap (formatCommand d) f

-- | Format a DateTime according to the format defined in the given format string.
-- | If the format string is empty, will return a `Left` value. Note that any
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could use a spot check on that statement. From what I could tell, the only situation that would return a Left value was if the string is empty (from List.some on 164), but literally anything else would parse as a Formatter and just have Placeholder for any unrecognized portions of the input string.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmm, I ran this:

quickCheck' 100_000 \str -> 
  (if str == "" then true else isRight $ parseFormatString str)
  <?> "Test failed for input '" <> str <> "'"

and got

Test failed for input 'ᆌH졶簮'

So any advice what this message should say?

-- | Format a DateTime according to the format defined in the given format string.
-- | If the format string is empty, will return a `Left` value. Note that any
-- | unrecognized character is treated as a placeholder, so while "yyyy-MM-dd" might
-- | not produce the format you want (since "yyyy" and "dd" aren't recognized formats),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This statement would become inaccurate if #37 were implemented and merged.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll go ahead and change that too while we're sanding off rough edges. The comment still holds true for yyyy though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll update this comment with the assumption that "d" will be an accepted format then.

Comment on lines 234 to 236
-- | Format a DateTime according to the format defined in the given format string.
-- | If the format string is empty, or contains astral plane characters (i.e., unicode
-- | code points that aren't representable in a single code unit), will return a `Left` value.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could use a spot check on this statement. I originally thought that only empty strings could produce a Left value, but checked that with QuickCheck, and got "ᆌH졶簮" as another value of an input that produces Left. I'm pretty sure this is because those are astral plane characters that aren't representable via Char, which is used in placeholderContent up on 132. But honestly, I'm not the most familiar with unicode and code units vs. code points.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like I should fix the parser to support a better unicode range rather than having to do documentation gymnastics to excuse it 😄. Let's remove the statement, and I'll take a look at fixing it.

Copy link
Member

@garyb garyb Mar 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hah! It took a minute to figure it out, as I was going down the unicode track, but the reason that input fails is because of the H in there - it's a partial formatter command.

The parser is expecting HH, so throwing a failure when it fails to see another H after the first one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤦‍♂️
ugh, that's embarrassing. Okay I'll update this.

-- |
-- | while `printFormatter (Hours24 : MinutesTwoDigits : Nil) = "HHmm"`.
-- |
-- | The interpretation of the format string is inspired by [momentjs](https://momentjs.com/docs/#/displaying/format/).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest we just mention this somewhere once, rather than on every function that deals with a format string. Probably in the same place we explain the format!

We could perhaps the format info we have in the README just now in a module header comment, as that way it'll be contextually available in the pursuit docs too.

Comment on lines 234 to 236
-- | Format a DateTime according to the format defined in the given format string.
-- | If the format string is empty, or contains astral plane characters (i.e., unicode
-- | code points that aren't representable in a single code unit), will return a `Left` value.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like I should fix the parser to support a better unicode range rather than having to do documentation gymnastics to excuse it 😄. Let's remove the statement, and I'll take a look at fixing it.

-- | Format a DateTime according to the format defined in the given format string.
-- | If the format string is empty, will return a `Left` value. Note that any
-- | unrecognized character is treated as a placeholder, so while "yyyy-MM-dd" might
-- | not produce the format you want (since "yyyy" and "dd" aren't recognized formats),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll go ahead and change that too while we're sanding off rough edges. The comment still holds true for yyyy though.

@@ -63,6 +74,8 @@ instance showFormatter :: Show Formatter where

derive instance eqFormatter :: Eq Formatter

-- | The format string representation of a `Formatter`.
-- | The interpretation of the format string inspired by [numeral.js](http://numeraljs.com/#format)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same thing applies here as to the comment about moment.js. Also this information is news to me, I didn't know where it came from 😄 (I didn't implement this module).

@garyb
Copy link
Member

garyb commented Apr 8, 2023

🤦‍♂️ I thought I'd already returned to this.

Thanks very much for working on it an apologies about the extremely slow turnaround on my part!

@garyb garyb merged commit 764fb91 into purescript-contrib:main Apr 8, 2023
@ntwilson ntwilson deleted the update-docs branch April 8, 2023 17:13
@ntwilson
Copy link
Contributor Author

ntwilson commented Apr 8, 2023

No worries! Glad to help out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants