worldTime is the number of game ticks that has elapsed since the start of the world. Which happens to be 20 each second. (0.05 seconds)
A redstone tick happens every other tick (to allow for other updates to happen between redstone ticks, otherwise redstone intensive stuff would really bog the game down. (A mod was made a long time ago that made redstone operate on each game tick. Which not only made the game very sluggish but also caused a lot of issues with redstone torches etc. Either way it's besides the point.
It is important to know that any RedPower component set to a .05th of a second will run one cycle .05 seconds early/late and the next late/early. With a timer that makes the issue even worse since it needs to reset. Running it at 250 ms intervals means it will "tick" once at say 300 ms and once at 500 ms since it's first activation. A sequencer on the other hand will not have this problem, instead it will be set to "EmitSignal = 1, 2, 3 or 4" for each side (I made that up now) in a half redstone tick and the redstone will activate 50 ms late on odd cycles. But since it never needs to reset itself as it is synced to world time it never experiences any of the desyncing issues.
To answer your question(s) in short:
* worldTime is the number of GAME ticks elapsed since map creation. That starts the very moment you click "create world" in the menu and it starts generating the new world. To get Seconds from map start you take worldTime / 20. To get Hours, Minutes and Seconds since world time you do the same kind of math, for instance, minutes would be ((worldTime / 20) % 60) and so on.
* worldTime doesn't return seconds, it returns 50ms intervals passed since map creation. But that isn't the entire truth. If you suffer an FPS that is lower than 20 FPS at ANY stage in the game then your real life second just turned into a fraction of a minecraft second. Hence why, if you start a new world and start a stopwatch at the same time. Then set off a bunch of TNT til your PC lags and pick up the blocks. Your in game statistics will show a time elapsed that differs from your stopwatch.
That is also why making real life clocks (that is a clock that is synced with real life) is really hard. There is always the odd game tick that is "skipped" for whatever reason. (or as they say, late)
* A sequencer set to 1 second with a pulser on each side of it will pulse exactly once per second on the wire around it. (Every 10 redstone ticks)
Now i will have to look at the IC2 source... *sigh*
That will be your BIGGEST problem. So i was slightly wrong in that the reactor uses worldTime but still, timers are NOT to be trusted.
And what really happens with Timers isn't that they de-sync. It's that they sync, it is irrelevant to the problem at hand but i strive to be correct whenever i can. You can observe the same effects with BuildCrafts Redstone engines. Even if you start them with a 1 tick delay between each of them they will sync up with each other when they turn red. That's just the way things work and to find out exactly what is going on behind the scenes i would have to read a lot more source code. (And I'm not going to be doing that, i know Timers suffer from the issue but sequencers don't)
OK, before i finish this post off. The above random.nextInt(tickRate()); means that reactors will pick a random tick (between 0 and 19) on which to run on. That updateTicker is increased each game tick by one. So you need to figure out which of the 20 different game ticks the reactor is using no matter if you are using timers or sequencers. Build one and sync your machines to it, then remove the reactor and build it again and you will notice that it isn't in sync with your machines anymore. (20 BPS doesn't sound so bad anymore does it? )
Oh well, i am tired. I am sure that, with the information given, you will be able to find a way to make it work.
Ya you could've skipped a lot of the explanation there bud, I know a lot of how the ticks work, just not which worldtick described.
That aside, I see the problem. In fact, if it can be any of the 20 game ticks per second, then a sequencer and normal redstone in general could potentially be off by a single game tick, which could be a problem for me. I may have to use pistons to power things, just to get them to be on a game tick which is not a redstone tick... I'm surprised that the reactor ticks aren't necessarily in sync with the redstone ticks, but oh well. I think the easiest thing to do would actually be to sync the reactor, which would be pretty easy with 20 retrievers and some piston wiring, only thing is to keep it in one chunk so it doesn't resync crossing the border as things are wont to do. However, if it doesn't work give me a retriever which is on a game tick, I think I'd just replace the reactor till I got a redstone tick. Not sure what the best thing to do on SMP would be...
The trouble isn't so much with normal CASUC reactors, because (as you know and have shown), you can always just cram way more than are supposed to go in, and you'll be fine, but with breeder CASUC reactors, which need more precision. Of course, it still should work just fine without the reactor being perfectly synced, but it might be a bit more annoying to manage, and won't allow for the uranium to be changed out the instant it decays like I'd prefer to do. If it has to be a game tick behind though, so be it. If I can do it the instant it decays though, I'm hoping I can do it without stopping the reactor for a second every time I have to change the isotopes out.
Ugh. I really have no idea how I might build this on SMP practically speaking though without potentially using some piston powered wires to get it on a game tick, instead of a redstone tick. And are you sure RP stuff emits the signal alternating every other pulse like that (the late/early, early/late stuff)? Because I've already made a test using retrievers to sync the reactor, and when I use a piston to power 2 different rows of repeaters, you can tell that one fires just before the other, but it definitely isn't a full redstone tick later either because it is still visibly faster than a 3rd row which I set up which is a full redstone tick later.
Also, I've set up a timer in the past using 2 RP timers on the same line of redstone dust, and having one timer be turned on from piston timing (if you didn't know, when pistons connect wires, they take 3 game ticks to connect the signal, but have an instant disconnect), and the line definitely goes on every game tick, and tries to go off, but it isn't visible because the duration of both the timers' pulses is still 2 game ticks, so it is only ever off instantaneously. I was sure that it was going off because you could tell if you connected a door or other output. If I managed a pulse limiter that only sent a pulse for a game tick though, I'm sure it would go on and off every single redstone tick. I do remember it syncing back up to normal redstone ticks though once I unloaded and reloaded the chunk or world.
But based on my testing, I'm pretty sure that while the pulse length remains 2 game ticks, I'm sure they can be offset. They will reset whenever they get the chance (crossing a chunk border and the like), but they will stay as long as they don't cross the chunk border or otherwise become loaded and unloaded, meaning a single piston ought to be able to sync a sequencer to a reactor's tick, even if the server's reactor tick (which is unlikely to get changed) is stuck on a non-redstone game tick.