Is there any way to calculate milliseconds from DS1307
According to the DS1307 datasheet the SQW/OUT pin can produce a square wave at 1Hz, 4.096kHz, 8.192kHz, 32.768kHz.

The datasheets says:


  CONTROL REGISTER ...
  Bit 4: Square-Wave Enable (SQWE). This bit, when
  set to logic 1, enables the oscillator output. The frequency of the
  square-wave output depends upon the value of the RS0 and RS1 bits.
  With the square-wave output set to 1Hz, the clock registers update on
  the falling edge of the square wave. On initial application of power
  to the device, this bit is typically set to a 0.


So, if you have a spare MCU pin, your system could input that signal. AFAICT, that signal/information is not available via I2C, it is hardware only.

It still depends on how accurate you need milliseconds to be, and how much spare processor you have, you could use one of the higher frequency square-wave signals, and divide down to milliseconds in software. 

A simple binary shift (power of two division) would be cheap, but have a few % error. A more accurate division would need a bit more processing.

Edit:
Is this level of accuracy sufficient for your purpose?

Doing something that takes some time, and counting is a potentially fragile way to track time. Your code doesn't show anything which has any kind of time-driven constraint other than the speed of the UART. As the code may be printing different number of characters (e.g. in putsUART1(TIME);) then it isn't going to be very accurate. Worse, if there is any other processing to do, the timing loop will drift, potentially unpredictably.

When a system does not have a real-time clock, we normally we use a hardware timer, to maintain reasonably accurate time. However, you have a reasonably accurate clock in the DS1307, and the only hardware needed to track it is an input pin with an interrupt.

You wrote "Its working but don't know why it is missing 1second like after 34thsec it jumps directly to 36th sec."

It appears to miss the 35th second completely. That isn't really working. It is printing some numbers, which look like the right sequence, but that doesn't mean much. It is pretty easy to write a price of code that counts to 999 and prints. That doesn't mean each number took one millisecond to appear. 

If you want more specific help, you need to tell us how accurate the millisecond timer needs to be, and what other processing and peripherals your system is using.

I've only used PIC32 in very trivial ways, years ago (when they first appeared).

However, the PIC32MX795F512L has a bunch of hardware timers. So these could be programmed to create a reasonably accurate, stable millisecond timer. As well as being timers, they that can also count external events. So one timer could be used to synch with the DS1307.

However, I would just program a timer to be, say, a 0.5 millisecond timer, and occasionally synchronise that with the DS1307. if the PIC32MX795F512L is running from a crystal, it is going to be reasonably accurate. I'd let it run for a few hours, and compare with the DS1307 to understand the amount of drift between the two time sources.

Using the hardware timer will avoid the basic problem of using a 'busy-loop' to get timing.