You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working on #44 I added a test case for dates, and the expected file name becomes so long. 1996-01-27 becomes the ISO string 1996-02-27t00:00:00.000z. E.g. a potential file name would be /mock_data/pokemon/releasedate=1996-02-27t00:00:00.000z.get.json.
Question 1: How short is ok? YYYY-MM-DD or YY-MM-DD? With or without time of day? How short timestamp? HH-MM-SS is enough? Question 2: Should it be easy to override somehow? I'm thinking about scenarios in search API's or similar where the dates can change and would require multiple .json files to match. Maybe the date doesn't have a real impact on the UI design, like just outputting the date. But I can also think of scenarios where it does matter, like changing texts or colors depending on the date value.
The text was updated successfully, but these errors were encountered:
While working on #44 I added a test case for dates, and the expected file name becomes so long.
1996-01-27
becomes the ISO string1996-02-27t00:00:00.000z
. E.g. a potential file name would be/mock_data/pokemon/releasedate=1996-02-27t00:00:00.000z.get.json
.Question 1: How short is ok? YYYY-MM-DD or YY-MM-DD? With or without time of day? How short timestamp? HH-MM-SS is enough?
Question 2: Should it be easy to override somehow? I'm thinking about scenarios in search API's or similar where the dates can change and would require multiple
.json
files to match. Maybe the date doesn't have a real impact on the UI design, like just outputting the date. But I can also think of scenarios where it does matter, like changing texts or colors depending on the date value.The text was updated successfully, but these errors were encountered: