There is only one Epoch time anywhere at a time. This is an absolute value.
A value that approaches the number of seconds elapsed since the Age. The name of the coordinated universal time (indicated in seconds (tm_sec), minutes (tm_min), hours (tm_hour), days from January 1 of the year (tm_yday) and calendar year minus 1900 (tm_year)) is associated with the time represented as seconds from the era, according to the expression below.
Link http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15
Epoch time is measured from 01-01-1970 00:00:00 UTC . This is an absolute point in time, it does not apply to the time zone, since the UTC time zone is in the definition of an era.
Whenever you see a number for a date, such as your example 1462475106000 , it should be read in UTC/GMT . This is not a specific time zone value. Since time is a Unix-based number, by the definition of an era, time has passed from an era (in UTC), which makes it absolute.
(01-01-1970 00:00:00 UTC)(epoch) + 1462475106000 = Time in UTC
A date in a string is a different matter. It should include the time zone offset with the date part. The date will be considered time zone specific. Adding a time zone offset to it will convert it to an absolute value in UTC format. Without time zone information, a line date does not have an absolute value (point in time).
2016-05-05T18:55:08.000-07:00 = (2016-05-05T18:55:08.000) + (07:00 hrs) UTC or date + timezone offset = date - offset hrs UTC
Databases do not store dates in any timzon. They retain the absolute value of Unix time. The time zone setting in the databases is set so that the query output in a row is displayed in this time zone format. This parameter defines the format of the output date, not the value. Since the value is absolute, it is time independent.
This parameter also helps the database in determining the time zone of the date value that the user inserts if he skips the time zone offset. If the user is trying to insert a row column in a date column without a time zone database, try setting the row to the database time zone setting.
So 1462475106000 is the value in UTC as Unix time. This is not in EST .
If you need a date so that it is in EST , use the date in string format rather than in numeric format, since the number format is always UTC .
moment.tz.setDefault("America/New_York");
The above code will have no effect, since it is overwritten by moment.tz(data, "Asia/Kolkata")
Now consider the first entry in the first screenshot.
2016-05-06T04:35:06.000+5:30 (IST) = 2016-05-05T11:05:06.000-00:00 (UTC)
Comparing it with the second screen shot, since the time difference between the two is 4 hours, the second should be in the +01:30 time zone, if both of them are the same values in absolute time.
2016-05-06T12:35:06.000+1:30 = 2016-05-05T11:05:06.000-00:00 (UTC)
However, the child has a meaning
2016-05-05T19:05:06.000-07:00 = 2016-05-06T02:05:06.000-00:00 (UTC)
This is not the value indicated above. An interesting fact is that only part of the date in the child 2016-05-05T19:05:06.000 when adding IST offset +05:30 will become part of the date in the second screenshot.
2016-05-06T12:35:06.00 - 2016-05-05T19:05:06.000 = 5:30 (IST offset)
Leaving this aside, your ElasticSearch Java feeder code is probably the culprit.
Does not record the correct date and time combination in ElasticSearch. Try using the overloaded getDate() method getDate() int columnIndex, Calendar cal) in JDBC.
Sometimes the JDBC driver skips timezone information, forcing the date to be stored in the default timezone of the database using Calendar will cure this.
The same applies to the recording date.
void setDate (int parameterIndex, Date x, Calendar cal) throws SQLException