Date-fns: Why move towards such verboseness?

[corysimmons]

I went to format a Postgres timestamp with format(myTimestamp, 'MM/DD/YYYY') like I have a million times in the past, and got an error about myTimestamp now needs to use some parseISO function, so... okay. I added that... then I got an error about format needing to have some option enabled to understand unicode, so I added that then it still broke the date.

I messed around with it on RunKit and it worked as expected. I compared the versions and RunKit was still using 1.x where format is straightforward.

I think moving the lib from...

format(aTimestamp, 'MM/DD/YYYY')

...to...

format(
  parseISO(aTimestamp),
  'MM/DD/YYYY',
  { awareOfUnicodeTokens: true }
)

...is pretty nasty.

Am I missing something or is this the direction date-fns is moving towards?

[stefanprobst]

You could use the new formatting patterns

[corysimmons]

I'm happy to tweak formatting patterns a bit to adhere to a standard, but the format(parseISO(), 'xxx', { options... }) stuff is a lot. I think most people would want to parseISO and awareOfUnicodeTokens: true by default.

Perhaps date-fns could include a helper function like quickFormat(aTimestamp, 'MM-dd-yyyy')? 🤷‍♀️

[zackkrida]

for what it's worth, i just made a lil' helper function in my project for these changes:

const formatTimestamp = timeString => format(parseISO(timeString), 'xxx', { options... })

I'm torn on the verbosity— 👍 for adding flexibility and explicitness, but also, so much code 👎