Closed Bug 1713974 Opened 5 years ago Closed 5 years ago

Screenshot date shows day-of-month one higher than accurate

Categories

(DevTools :: General, defect)

Product:
DevTools
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1701461

People

(Reporter: firstpeterfourten, Unassigned)

Details

To reproduce:

  • Open any webpage.
  • Open Developer Tools.
  • If not previously done, open the three-dot menu in the upper right, and under Available Toolbox Buttons ensure "take a screenshot of the entire page" is checked.
  • Click this toolbox button, to take a screenshot of the page.
  • The file is saved to a Downloads folder with a name like "Screen Shot 2021-04-31 at 19.47.44-fullpage.png"
  • Later, notice that April has only 30 days, not 31.
  • Reproduce and notice that the date-in-month portion of the date is one day higher than the current date.
  • Suspect a zero-indexing vs. one-indexing overcompensation somewhere.
  • File/comment on this bug report.

Observed in at least v88.0.1 and some prior versions on Windows 10.

Component: Screenshots → General
Product: Firefox → DevTools

Hi, thanks for logging.
Can't reproduce this locally, screenshots seem to have the correct name for me.

We create the "day" part of this string with:

  const date = new Date();
  const dayString = date
    .getDate()
    .toString()
    .padStart(2, "0");

I don't see how this could lead to return 31 for the month of April.
Did you have the issue right when you filed the bug? Meaning it should have been end of May and not end of April?
Which timezone are you using? Anything relevant about the way the date is set on your system?

Flags: needinfo?(firstpeterfourten)

In my system time settings I have set time automatically On, set time zone automatically Off, time zone UTC-5 Eastern Time (US & Canada), Adjust for daylight saving time automatically On. This is Windows 10 running on bare metal; no opportunities for extra VM oddities.

In a test done just now, the date looks correct, but in a test done at the time of filing this bug a few days ago, it was not. The filing of the bug was motivated by going through some slightly older screenshots, for a task I was completing with a clear April 30 deadline burned in my brain, because I had to make some legal representations to another party that I had in fact completed the task on April 30. Fortunately, they were able to check their more detailed records and quickly agree that yes, I had done that, but having my own records with April 31 timestamps threw me for a concerning loop, since April 31 doesn't exist.

I agree that the quoted code looks correct, but am even more confident in having observed the bug described.

I am not sure if doing the test later in the day, after a GMT date changeover, might make a difference - e.g. if it's using local time but GMT date. However, even in that case, it should not produce April 31. It seems more likely that there is some manual adjustment where someone incorrectly thought they had to make an adjustment from a zero-indexed to a one-indexed system (as has to be done with the month).

Flags: needinfo?(firstpeterfourten)

I just tested in Windows 10 and it also works for me (the screenshot file name is correct for me).
Not sure how this could happen.
Honza

Looks like you were right! There is a bug which was recently fixed. Explains why the current code didn't seem wrong to me :)
Edit: this is fixed in Firefox 89, which was released last week.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE

Aha!
Thanks for finding that; I had gone through the full list of bugs on this component looking for a dupe before filing but didn't encounter that one.

You need to log in before you can comment on or make changes to this bug.