Short answer: Yes, fiery ball of doom.
Long answer: Thread.sleep() causes a, you guessed it, sleep on the current thread. By WPILib's design, your robot is instantiated in the same thread as the rest of WPILib and it's dependencies (the main thread). This means, say, if you were to use Thread.sleep(1000) and your robot is signalled by FMS to be disabled at that exact moment, your robot would (most likely) stay active for another 1000 milliseconds before finally disabling. Additionally, all your control data will be stalled. That means all your motor controllers and what not will stay at their current speed until the sleep is over. This also holds true for 'blocking' functions, such as .read() coming from Serial Ports and Networking Code. Wall of text over, just thought I'd explain it a bit more.

There are 2 ways I would suggest fixing your issue, should it appear some other time and your solution for your subsystem doesn't quite apply.
1) At the start of your routine record System.currentTimeMillis(). This will store the current unix time of the system. Each time your robot does an iteration, check if the new currentTimeMillis() subtracting the stored time is greater than or equal to 1000 (your time period). This has the advantage of not requiring any new Threads as well as being fairly low cost and easy. Keep in mind you shouldn't use this if you need /exactly/ 1000 milliseconds, as WPILib does an iteration every 20ms, or when new control data is available, whatever comes first.
2) Start a new Thread to execute the action. This isn't recommended as it's both kind of messy, easy to break and very easy to bug out. If you do use it, I would recommend a ThreadPool (ExecutorService). The advantages however are that you can get extremely accurate timings.

I hope that wall of text wasn't too much, I just though I'd explain how this kind of thing works in a bit more detail. Hope it helped, have a good day c: