As I mentioned earlier, Windows also implements the Win32 clock provider as an event provider, which works with the __InstanceModificationEvent event class to deliver notification events in response to WQL event queries. The WQL event queries
Select * From
__InstanceModificationEvent
Where TargetInstance ISA
'Win32_LocalTime'
and
Select * From
__InstanceModificationEvent
Where TargetInstance ISA
'Win32_UTCTime'
trigger a notification every time the local time and UTC time change. Because both target instances change every second, WMI will notify the subscriber (i.e., the application that submits the event query) every second.
Note that the queries don't use the WITHIN condition, although they could. WQL event queries that use WITHIN don't leverage the WMI event provider capabilities. When a WQL event query specifies the WITHIN condition, it's requesting the core WMI subsystem to execute the query. In such a case, the core WMI subsystem, with the help of the provider that supports the requested target instance, polls for a change in status and waits until the end of the polling cycle to notify the subscriber of any change. Although this approach works fine, it's slower than an event query supported by an event provider. If you omit the WITHIN condition, a WMI event provider handles the WQL event query and returns notifications as changes occur. The WMI subscriber doesn't have to wait until the end of a polling cycle to be notified; the notification immediately follows the change. . . .

