30-seconds-of-code: [BUG] toEnglishDate not working

[fejes713]

[BUG] snippet toEnglishDate does not work as it should.

When running

toEnglishDate('09/21/2010')

the output of the function is '2010/09/20'

Expected Snippet Behavior

the output of the function should be '21/09/2010' as said in the snippet description.

[atomiks]

const toEnglishDate = (date, delim = '/') => {
  try {
    return new Date(date)
      .toISOString()
      .split('T')[0]
      .split('-')
      .reverse()
      .join(delim);
  } catch (e) {}
};

still outputs the day earlier...

[skatcat31]

Notice the time offset when you enter the date into new Date(). Unless absolutely specified with a time zone, the date will parse as local time then output as UTC. If you are ahead it can revert back a day, if you are behind it can be brought forward a day. This is due to the implementation of ISO8601 date libraries

[skatcat31]

Simple fix could be seeing if there is UTC in the string, and if not appending it to the end. However by making it use Date we can accept ANY valid input to the Date constructor and get valid output.

Example: insert an epoch

[Chalarangelo]

I believe accepting any valid date as argument should be what we end up with, but the behavior described by @skatcat31 makes me wonder if we should keep this snippet to begin with or actually remove it for good. I mean date libraries are huge and deal with things like these by handling a ton of edge-cases, which is definitely something we want to avoid. Maybe we should retire the snippet altogether or something like that? Otherwise it will still end up with wrong results if it skips around dates and there's not much we can do without making it long and complicated.

[fejes713]

Maybe we should retire the snippet altogether or something like that?

As you said:

date libraries are huge and deal with things like these by handling a ton of edge case.

and there's not much we can do without making it long and complicated

I will remove it 👍

[kingdavidmartins]

I concur @fejes713 @Chalarangelo

I also vote to remove 👍

[skatcat31]

It has it's uses, but implementing it to accept valid dates requires a library no matter what. It'd be easier for programmers to learn the date library of choice and use that instead and we should make a function that accepts an ISO8601 string and makes it an English date if we want this functionality back

[Chalarangelo]

@skatcat31 I wouldn't really say this functionality is something that has to be in the codebase. After all, if you need to convert from one date format to another in a string, it's pretty easy to do and if you need anything more, you will be using a library anyways, so I'd rather lay this one to rest and move on to other issues.

[skatcat31]

It was more a PS thought. Otherwise I would have reopened this issue. I merely pointed out that IFF( IF and only IF ) we wanted to implement this again, the footprint would need to enforce ISO8601 ONLY strings, no date objects, etc.

In it's current state I couldn't agree more it should be removed. Especially since we have many other snippets that show string manipulation.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for any follow-up tasks.