I have a CKFinder UI in a ColdFusion application to manage file uploads. In migrating our application to AWS, and preparing it for running it in an array of load balanced servers, we moved the file repository from a folder local to the application to an S3 server. The only change made to the configuration was in setting the base path to the S3 server, which is mapped to our servers as a remote drive using TNTDrive.

The change works fine in Chrome, but after uploading the file in Firefox, we get the following error thrown by CKFinder: 'Unparseable date ""'. The file is uploaded as expected, so my first thought was that the date display for the file was not working for Firefox. We had the file display include the filename, date of upload, and file size. I disabled the date display and still get the error. Additionally, refreshing the page does not make this error go away, but navigating to another page and returning does, with the uploaded file displaying correctly.

One additional thought I had that might provide a clue is that S3 runs in UT and we have our servers set for Mountain Time. Perhaps this is something Firefox is particularly sensitive to? This is a legacy of our previous server that we do intend to remedy in the near future (we have a number of features that are dependent on MT).

Dani AI

Generated

Following 's report and 's comment, this looks like a client-side date-parsing problem rather than a failed upload. Chrome's JS engines are forgiving about nonstandard or empty date strings; Firefox is stricter and will throw "Unparseable date \"\"" when it encounters an empty or badly formatted value while the UI tries to parse and render file metadata. The fact the file is present after a full navigation but the immediate upload UI errors supports that theory: upload completed, UI update hit a bad date value.

Practical checks to run in Firefox Developer Tools:

  • In Network (XHR), perform the upload and inspect the upload response and any follow-up file-list response for the new entry. Look for a date/timestamp field that is empty, missing, or formatted in a non-ISO way (for example a space-separated timestamp rather than ISO 8601).
  • Check the Console for the stack trace so you can see which CKFinder JS routine attempted the parse.
  • Compare the same responses in Chrome to see whether Chrome silently accepts the value that Firefox rejects.

Fix options, in order of preference:

  • Return a standards-compliant timestamp from the server (ISO 8601 with timezone or epoch milliseconds). That is the most robust fix across browsers.
  • If the storage/mapping layer cannot supply a date immediately, return null/omit the field instead of an empty string so client code can skip parsing.
  • Add a small client-side guard in the CKFinder update/formatter to skip parsing when the value is falsy and render a placeholder.
  • Consider updating CKFinder or using a direct S3-backed integration if the mapped filesystem strips or mangles metadata.

Note: timezone differences usually do not produce an "Unparseable date" unless a required timezone/token is missing or the value is an empty string. Capturing the exact XHR payload and the console stack trace will quickly show whether the problem is an empty value, a nonstandard format, or a CKFinder parsing bug.

2 thoughts here. I've lost count of apps that rely on timezones. Lucky me I was exposed early to that trouble with UNIX (yes, UNIX, not Linux) long ago so GMT was always the choice with the TZ adjusted for each user and interface/app.

But where's the code that is tossing up the error? If it's inside some commercial app/helper then you should be at their doorstop to ask for a patch or explainer to work around it. I don't mind looking at code but here I don't see code.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.