Timestamps and the PC clock vs. time on the net are different and I'd say somewhat unrelated concepts.
You are worried about accuracy of the current time. Timestamps have nothing to do with current time, but are a way of identifying and particular moment in time.
Yes, the PC clock gets its time from the net assuming the time server settings are all set properly. Even the correction of the current PC time may not happen exactly when the leap second gets inserted. It may be some time before the PC resynchronizes with the net time. The PC doesn't know if the existence of when a leap second will occur. And neither does the LabVIEW timestamp.
Here is an example. According to http://en.wikipedia.org/wiki/Leap_second, a leap second will occur at the end of June 30 of this year UTC. Since my clock is eastern daylight time at that date, I put together an example for 8pm on June 30 (UTC +4). You'll see that the 3 values (a second before, the exact time, and a second after) show they are all 1 second apart. There is no extra second accounted for. So in real life the time a second after vs. a second before are actually 3 seconds apart, but LabVIEW only show 2 seconds. Feel free to play with the attached snippet for different timezones and daylight savings time and all of that.
I don't think you really have as big of a problem as you are trying to investigate here. If your timing needs are that critical where you need accuracy of the current time to better than a second, then you shouldn't be looking at LabVIEW timestamps, PC time clock, or internet time at all, but look at a high accuracy timing source perhaps based on a GPS clock.
Unless you have a particular test planned to run over the expected point of time where a leap second is inserted, then you shouldn't have to worry. Even if you do have a test run over the leap second, you probably don't need to worry either. If the test is based on a waveform datatype, then you have a T0 timestamp, and a dT that will keep track of all the individual data points accurately.
