This is definitely something you should worry about if you rolled any of your own time code. The POSIX standard is consistent across days, including leap seconds. That means that your Unix timestamp will jump back a second: it will go from 1341100800.9...[0] to 1341100800. If you're relying somewhere on seconds being continuous, or on a one-to-one mapping between timestamps and seconds, this could fuck things up.
Although 1341100800 refers to two seconds, when converting to UTC it should always become 00:00:00. Your implementation may not be conforming to the standard, though. Make sure to test.
(I'm sure if you rolled your own time code, you already know about this stuff. Probably other folks are curious though :)
[0] I think this is the second we're talking about, not positive though.
I've found or read about bugs in nearly every stdlib time library I've ever worked in, except Joda time[1].
If you rolled your own, you should worry more, but you should still think about it even if you didn't roll your own.
[1] Joda is awesome, and by far better than any other time lib out there, but even they have bugs they're fixing in JSR310 (http://jcp.org/en/jsr/detail?id=310)
Although 1341100800 refers to two seconds, when converting to UTC it should always become 00:00:00. Your implementation may not be conforming to the standard, though. Make sure to test.
(I'm sure if you rolled your own time code, you already know about this stuff. Probably other folks are curious though :)
[0] I think this is the second we're talking about, not positive though.