Windows settings time

[Gijsreyn]

• I have signed the Contributor License Agreement.
• This pull request is related to an issue.

---

Addresses issue #34 and #100

[Gijsreyn]

@ryfu-msft And this one. There is still an issue that I have opened at PSDesiredStateConfiguration.

[Trenly]

Should probably be a validate script; Ref your linked issue - PowerShell/PSDesiredStateConfiguration#125 (comment)

[Gijsreyn]

The only thing that I can think of, is create a enum without the spaces, and add another helper function to translate it. Might be a bit overkill, so I'm curious what the PS team is going to mention.

[Trenly]

If you're not going to add it in this PR, once this PR merges I would request that you add a follow up issue to track the addition of adding clocks for different timezones under HKEY_CURRENT_USER\Control Panel\TimeDate\AdditionalClocks\1

[Gijsreyn]

I'll put it on #100

[Gijsreyn]

@Trenly I have partially started on this one. Do you mind sharing your thoughts on #100 how we are going to set both 1 and 2 in the registry?

[Trenly]

I would implement it as a single AdditionalClock resource, which has Properties of Ensure, TimeZone, DisplayName.

For Get -

• Fetch the values in 1
• Compare against properties
• If the properties match, set ensure present and return the current state
• If the properties don't match, fetch the values in 2
• Compare against properties
• If the properties match, set ensure present; otherwise, set ensure absent
• Return the current state

For Test -

• Run Get
• Compare Ensure of the current state to Ensure of the desired state
• Return result of comparison

For Set it's a bit more complicated, I'd imagine you'd first want to determine if either 1 or 2 had a matching DisplayName, if it does, set the values for that clock. If no display names match, check if either timezone matches, if it does, set the values for that clock. If neither are a match, put it in slot 1 if the enable property of the slot is not set. If slot 1 is already enabled, put it in slot 2 if the enable property of the slot is not set. If slot 2 is already enabled, throw an error that the maximum number of additional clocks have been set.

---

Alternatively, you could just add a parameter for Id and restrict it to being 1 or 2 and have it be mandatory for Set operations but optional for Get and Test. That's honestly probably the better option

[Gijsreyn]

Thanks for the details. One small question, how will users be able to specify both 1 and 2 in a single configuration document?

[Trenly]

They call the resource twice - once for setting slot one, and a second time for setting slot two

[Gijsreyn]

I lack the knowledge on this part. Either clock 1 or clock 2 can be turned on, or both. Shouldn't the user be able to say something like: AdditionalClock1Settings and AdditionaClock2Settings?

[Trenly]

No need; They can confugure like:

    - resource: Microsoft.Windows.Setting.Time/AdditionalClock
      directives:
        description: Set clock 1
        allowPrerelease: true
      settings:
        Slot: 1
        DisplayName: UTC
        Timezone: UTC
        Ensure: Present
    - resource: Microsoft.Windows.Setting.Time/AdditionalClock
      directives:
        description: Set clock 2
        allowPrerelease: true
      settings:
        Slot: 2
        DisplayName: Current time in Redmond
        Timezone: Pacific Standard Time
        Ensure: Present

[Gijsreyn]

Ah cool. I'll pick it up after this is merged!

[Gijsreyn]

@denelon I'm adding you to the chain as well because I can remember you making a remark in the past that you were checking with the Windows team on registry keys. When spawning up a fresh machine from DevHome, I noticed something odd that I hadn't seen before.

I just learned about the privacy and security settings, but they bite this PR (a bit). For now, I have added an additional check on the relevant registry keys I could capture when SetTimeZoneAutomatically is $true, but I'm curious about your thoughts. Should we test this, and if it is disabled, don't we do anything? Or do we just continue?

[denelon]

That's a great find!

What settings are getting applied here, and what happens if we don't enable the location permissions?

[Gijsreyn]

Users must manually enter the time if the location permissions aren't set.

[ryfu-msft]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ryfu-msft]

How do you feel about moving things like SetTimeAutomatically to a separate DSC resource called Time.
When I look at the settings page for TimeZone, I only see SetTimeZoneAutomatically and if that is not true, then we have the option to set the TimeZoneId and DaylightSaving. I think this DSC resource should try to replicate what we see in the settings app. I think this is the best way to prevent scope creep for this individual DSC resources.

[Gijsreyn]

That's precisely why I did it into one DSC resource. They bite each other. Even if we separate them both, we have to check what options are already enabled in both cases. If we set the Timezone to automatically, we might need to clean up the manual settings and vice versa.

[ryfu-msft]

This value is not dependent on whether the time zone supports daylight saving or not. This should just be a registry check.

[Gijsreyn]

I didn't totally get you here. It is checking the registry with the GetDayLightSavingStatus() method?

[ryfu-msft]

I feel that this should be its own separate DSC resource for just Location. I'm sure there are other settings that will depend on this, not just Time/TimeZone.

[Gijsreyn]

Partially, as it affects the TimeZone setting, what's your suggestion? A custom module to inherit those functions?