#9275 Fix issue Invalid date on Firefox #9393
Conversation
…ormat as 2nd param to moment
mahmoudadel54
changed the title
| @@ -26,7 +26,7 @@ const dateTimeFormatter = ({value, format, type}) => { | |||
| ? moment.utc(value).format(format) | |||
| : type === 'time' | |||
| ? moment(`${DEFAULT_DATE_PART}T${value}`).utc().format(format) // time format append default date part | |||
| : moment(value).format(format) // date or date-time formats | |||
| : moment(value, format).format(format) // date or date-time formats | |||
There was a problem hiding this comment.
The input format should not be the same as the output format. This function is taking a raw date/date-time/time value from feature and convert it to configured format for visualization so we expect:
moment(value, 'YYYY-MM-DD[Z]').format(format)
We should apply the input format when the type is only date and the value ends with Z, in general is a good practice to apply the input format when known as suggested here.
The current implementation is not working if you try to replace the localConfig configuration of FeatureEditor with custom formats:
- "FeatureEditor",
+ {
+ "name": "FeatureEditor",
+ "cfg": {
+ "dateFormats": {
+ "date-time": "MM DD YYYY - HH:mm:ss",
+ "date": "MM DD YYYY",
+ "time": "HH:mm:ss"
+ }
+ }
+ },There was a problem hiding this comment.
I check momentjs documentation for this point and I saw something I think it may be helpful.
If I don't know the exact input format, I can pass all the available date formats in an array (list) and it will match the correct one from the list.
check this image:
tdipisa
added
the
BackportNeeded
…known in case date format with value ends with 'z'
|
@ElenaGallo please test this fix on dev and let us know if we can backport on 2023.02.xx, thanks |
|
Test passed, @mahmoudadel54 please backport this PR to 2023.02.xx, thanks |
ElenaGallo
removed
the
BackportNeeded
…notation * commit 'bed88971c58ab68dbfb33183eacaef8481fd0954': Adding clause in documentation for google photorealistic 3D tiles (geosolutions-it#9458) (geosolutions-it#9460) geosolutions-it#9275 Fix issue Invalid date on Firefox (geosolutions-it#9393) (geosolutions-it#9451) geosolutions-it#9163 Bug 3D Tiles offset with Google 3D tiles (geosolutions-it#9421) (geosolutions-it#9450) geosolutions-it#9269 fix issue of correct map embed url in sharing map (geosolutions-it#9395) (geosolutions-it#9452) geosolutions-it#9310 Annotation not works with sideBarmenu (geosolutions-it#9402) (geosolutions-it#9449) set resolve.fallback.http/https/zlib to false in webpack extension build config (geosolutions-it#9375) (geosolutions-it#9445) geosolutions-it#9422 Zoom level issue on OpenLayers (geosolutions-it#9429) (geosolutions-it#9442) geosolutions-it#9362 3D Styling issue (geosolutions-it#9403) (geosolutions-it#9441) geosolutions-it#9363 Wrong scale value reported using the scroll wheel (geosolutions-it#9401) (geosolutions-it#9440) geosolutions-it#9366 Problems with Bearing measurement (geosolutions-it#9400) (geosolutions-it#9439) geosolutions-it#9346 ensure the zoom is always round before using it as index (geosolutions-it#9357) (geosolutions-it#9438)
Description
The PR implements fixing the issue when opening the attribute table of a layer with date attributes on Firefox, it display "Invalid date" instead of the date.
Please check if the PR fulfills these requirements
What kind of change does this PR introduce? (check one with "x", remove the others)
Issue
What is the current behavior?
#9275
What is the new behavior?
When opening the attribute table of a layer with date attributes on Firefox, it display the date in this format "YYYY-MM-DD[Z]" for example 2022-02-10Z.
Breaking change
Does this PR introduce a breaking change? (check one with "x", remove the other)
Other useful information