The answer by Jon Skeet is correct. I'll add a few thoughts.
Unix time means different things to different people. As that Wikipedia article describes, the basic idea is usually a count of seconds since epoch, with epoch being the first moment of 1970 in the UTC time zone. As the name suggests, this approach to time tracking was used in Unix-like operating systems.
Locality
Does it vary by locality? No. By definition, it represents UTC time zone. So a moment in Unix time means the same simultaneous moment in Auckland, Paris, and Montréal. The UT
in UTC
means "Universal Time".
Is Unix time universal in the sense of used everywhere? No, certainly not.
Granularity
First, the granularity. As computer clock chips became more precise, conventional computer systems moved to tracking time by millisecond, microsecond, and even nanosecond. Different software assumes different granularity of time tracking. The java.util.Date/.Calendar classes and Joda-Time library both use millisecond resolution, while the newer java.time package built into Java 8 assumes nanosecond resolution. Some databases such as Postgres typically assume microsecond resolution.

To quote the Question…
I am getting the UNIX time in milliseconds
Technically a contradiction in terms, as traditional Unix time or POSIX time is tracked by whole seconds rather than milliseconds.
Epoch
Secondly, the epoch. The first moment of 1970 is far from the only epoch used by various computer systems. A couple dozen epochs have been used, some with very wide usage. For example, Microsoft Excel and Lotus 1-2-3 spreadsheets, Cocoa, GPS satellites, Galileo satellites, DOS & FAT file systems, and ntp (Network Time Protocol) each using a different epoch ranging from the years 1899 to 2001.
Avoid Count-From-Epoch
Generally best to avoid focusing on handling date-time values by counting milliseconds (or any granularity) from epoch. Such values are difficult to read and comprehend by humans thereby making debugging difficult and mistakes non-obvious. Add on the possible mistakes from assumptions about the granularity and/or epochs discussed above.
Instead use a decent date-time library. In Java that means either:
Do you track text by collecting groups of 7 or 8 bits? No, you use classes and libraries to do the heavy-lifting of handling character sets, character encoding, and such. Do the same for date-time work.