yamaguchi@: Could you confirm? Thank you!

There are 2 thing we need see with this issue:
1. It does not open dialog because user is not allowed to change date/time nor timezone. We could disable the button in such case to be consistent.
2. Why the user begin to be unable to change time setting here?

So far I am seeing that SystemClockClient once requests and receives CanSet value, and it is false in the screen before sign in and OOBE.
To fukino@: Did we recently change anything with the execution context like the used user here, permission or capabilities for OOBE / sign in?

I didn't touch any code about execution contexts or system clocks when I worked on the ext4 migration screen.

I think this can be punted to M71 because there is workaround, either by signing in with an account or guest.
Raise priority if this is considered more important.

Added AccountManager components label, because this happens reflecting the capability of the sign-in profile rather than being a UI bug.
- user cannot modify clock while in the sign-in profile
- user cannot modify clock while in the OOBE
Are these intended?

Adding rkc@ and SignIn component label.

Removing AccountManager label since it is something totally different :)

Could it be because time (and time zone) has synchronized and thus time is no longer considered user-managed?

Yes. We should verify that the date button is not clickable once the clock has synced (to confirm that there isn't a bug here with the dialog improperly being accessible the first time around) but otherwise no action is needed.

I confirmed it's after syncing the clock via network as noted in comment #14.
Would it be correct to show UI for users to override just the timezone (but not the clock) in this case?

1. boot
2. chromeos::SystemClockClient request and receive CanSetClock = true  from the DBus service.
3. clock synced
4. chromeos::SystemClockClient request and receive CanSetClock = false  from the DBus service.

Some notes for testing:
This basically happened only at the first boot after powerwash on my environment.
However I could reproduce this for the second time boot after powerwash, by keeping the device disconnect from the network at power-on step. (Otherwise it perhaps receive time sync before OOBE welcome screen appears.)

Based on the investigation so far this is not related to Accessibility.
Additionally I think this can be P3 because this doesn't prevent a substantial operation by user.
(As the dialog says, the dialog should be needed only when Chrome OS cannot adjust the system clock automatically.)
Also removing from M71 list accordingly.

As a conclusion, this is WAI with our current design. If we allow to open the dialog under this condition, the dialog message would not be consistent with the actual state of the system, and user will not be able to actually change the system clock.

However, permission to change clock and change timezone are different things. Therefore we may consider adding another UI flow to just change the timezone settings.

I'll point out that I don't know of any network requirement to change the time zone - the user should be able to sign in and change the time zone from their user session in Settings.