p-calendar and p-columnFilter with stateStorage : p-calendar somehow selects a UTC date which is not properly converted while restoring state

[LouLeGrain]

Describe the bug

This is a weird one :
I have a p-table, with state stored in the session storage. It has date filters.

1. I select a date to filter
2. The date is UTC somehow (i know UTC support has been deactivated but still...)
3. When using JSON.stringify it is stringified as "2024-03-01T00:00:00.0Z"
4. Then it is stored like that in the session storage
5. Refreshing the page, when restoring the filters, the regex test for dates in the reviver function of restoreState() fails because it expects a timezone with 3 numbers

One of the fix would be to modify the regex to be /\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.\d{1,3}Z/ in table.ts line 2813

---

Here is the code for my table filter

<p-table #table [value]="items" dataKey="id"
      stateStorage="session" stateKey="consignes-list"
      [rowHover]="true" [loading]="loading$ | async" [resizableColumns]="true"
      [paginator]="true" [rows]="20"
      [showCurrentPageReport]="true"
      [currentPageReportTemplate]="'item {first} à {last} sur {totalRecords}'"
      [rowsPerPageOptions]="[10, 20, 50]"
      [(contextMenuSelection)]="rightClickedItem" [contextMenu]="cm"
      styleClass="p-datatable-striped p-datatable-sm" >

      <ng-template pTemplate="header">
        [...]
          <th pResizableColumn class="text-center">
            <p-columnFilter type="date" field="finValidite">
              <ng-template pTemplate="filter" let-value let-filter="filterCallback">
                <p-calendar [ngModel]="value" (onSelect)="filter($event)" appendTo="body"></p-calendar>
              </ng-template>
            </p-columnFilter>     
          </th>
        [...]

Environment

Chrome version on Mac OS

Chrome Version 123.0.6312.59 (official build) (arm64) on MacOS

navigator.appVersion = '5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36'

Tested on safari too, the bug is still there

Angular / PrimeNG Version

"dependencies": {
[...]
    "@angular/common": "^16.1.2",
    "@angular/compiler": "^16.1.2",
    "@angular/core": "^16.1.2",
    "@angular/forms": "^16.1.2",
    "@angular/platform-browser": "^16.1.2",
    "@angular/platform-browser-dynamic": "^16.1.2",
    "@ngx-translate/core": "^15.0.0",
    "primeicons": "^6.0.1",
    "primeng": "16.0.2",
[...]
 },

Reproducer

No response

Angular version

16.1.2

PrimeNG version

16.0.2

Build / Runtime

Angular CLI App

Language

TypeScript

Node version (for AoT issues node --version)

20.5.1

Browser(s)

Chrome, Safari

Steps to reproduce the behavior

1. I select a date to filter
2. The date is UTC somehow (i know UTC support has been deactivated but still...)
3. When using JSON.stringify it is strigified as "2024-03-01T00:00:00.0Z"
4. Then it is stored like that in the session storage
5. Refreshing the page, on restoring the filters, the regex test for dates fails because it expects a timezone with 3 numbers

Expected behavior

Date should not be UTC, or the regex used in the reviver function should handle it.

[LouLeGrain]

Here is a more throughout investigation with the date being UTC.

1. Breakpoint at primeng-calendar.mjs at this line
2. right click on the newly created date object on the local scope (right column in the debugger), then "store as a global variable"
3. then in my console i have the date accessible with the name temp2
4. JSON.strigify(temp2) gives '"2024-03-01T00:00:00.0Z"'
5. temp2.toISOString() gives '2024-02-29T23:00:00.000Z'

[LouLeGrain]

I tried to replicate the issue (with primeng v16.9.1 because 16.0.2 won't compile in stackblitz because of #13024 .

But i could not replicate the issue, it works fine (the stackblitz)

It happens only in the state of our app, in dev but also in prod.

I guess i'll have to upgrade the Angular & primeNG versions...

[LouLeGrain]

Anyway, i migrated the app to Angular 17, with primeng 17.12.0 and the bug's still there, on macos and windows, local dev or server deployed.
Looks like the problem's on my side.
I'm closing the issue.

[LouLeGrain]

As expected, i finally found some prototype pollution on my Date type.