0

I have some client-side JavaScript code which reads a string and tries to parse it into a Date() object via new Date(theString), displaying the resulting Date as a UTC string to the user. If it's a string that can't be turned into a Date, of course, it becomes an Invalid Date, in which case instead it displays "Not a date/time."

I also have some server-side Python code which essentially does the same thing: takes the user-submitted maybe-a-date, and stores it as either a UTC string or as "not a date".

The trick is, I need the two pieces of code to always behave exactly the same on every single string. I could certainly just make a tiny Python endpoint that uses the existing Python code to send the appropriate response back to the client instead of using Date() client-side, but for various reasons that's an undesirable solution.

So is there a way to translate strings into dates in Python that's guaranteed to work exactly the same way as new Date(myString) does in JavaScript?

DanM
  • 7,037
  • 11
  • 51
  • 86
  • 1
    Why don't you accept a single standardised format, like https://en.wikipedia.org/wiki/ISO_8601? – jonrsharpe Apr 01 '20 at 18:19
  • Dare to dream :) A key element of this is accepting lots and lots of date/time formats. – DanM Apr 01 '20 at 18:19
  • 1
    Because what? Context is helpful. – jonrsharpe Apr 01 '20 at 18:20
  • Well, the question is a simplified version of the real problem for the sake of clarity. The reason is that we're trying to give users the ability to upload existing CSV files, with non-standardized formats, in a way that we can read them, without making the users do any more processing on their end than absolutely necessary. – DanM Apr 01 '20 at 18:22
  • Then fix them locally, convert to 8601, and pass to the API...? – Austin T French Apr 01 '20 at 18:24
  • 2
    "I could certainly just make a tiny Python endpoint that uses the existing Python code to send the appropriate response back to the client instead of using Date() client-side, but for various reasons that's an undesirable solution"—if you can't use ISO-8601 or similar, and especially if "a key element of this is accepting lots and lots of date/time formats", this is your best option for _guaranteeing_ consistent behaviour. – ChrisGPT was on strike Apr 01 '20 at 18:24
  • Alas @AustinTFrench we have to do the transformation client-side (long story) – DanM Apr 01 '20 at 18:25
  • @Chris right, that's the potential solution I mentioned in the question; my hope was to avoid that so the "preview" on the client side could be lag-free regardless of connection speed. – DanM Apr 01 '20 at 18:27
  • 1
    (Aside: are you sure that different JavaScript implementations will always be the same? There are no corner cases where IE does something different from Chrome, or Firefox different from Safari? I'm not sure about that. Which one are you trying to standardize on?) – ChrisGPT was on strike Apr 01 '20 at 18:27
  • 1
    @Chris now THAT is a very good point I hadn't thought of, which is making me think the endpoint solution might be the only acceptable one. – DanM Apr 01 '20 at 18:28
  • Take a look at the `arrow` library. https://arrow.readthedocs.io/en/latest/ – Daniel F Apr 01 '20 at 19:05

1 Answers1

0

So is there a way to translate strings into dates in Python that's guaranteed to work exactly the same way as new Date(myString) does in JavaScript?

No.

It's impossible, because:

  1. Parsing of strings other than the two formats specified in ECMA-262 is implementation dependent and it is easily demonstrated that different implemetations parse the same string differently (e.g. Why does Date.parse('COVINGTONOFFICE-2') return a real date?)
  2. How various implementations parse unsupported formats is not documented, so you can only determine the rules through observing behaviour of every possible string, including those that look nothing like a date, in every implementation, then knowing which implementation you were trying to imitate
RobG
  • 142,382
  • 31
  • 172
  • 209