Github user bitblender commented on a diff in the pull request: https://github.com/apache/drill/pull/600#discussion_r82314071 --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/store/parquet/ParquetReaderUtility.java --- @@ -45,4 +53,34 @@ public static int getIntFromLEBytes(byte[] input, int start) { } return out; } + + /** + * Utilities for converting from parquet INT96 binary (impala, hive timestamp) + * to date time value. This utilizes the Joda library. + */ + public static class NanoTimeUtils { + + public static final long NANOS_PER_DAY = TimeUnit.DAYS.toNanos(1); + public static final long NANOS_PER_HOUR = TimeUnit.HOURS.toNanos(1); + public static final long NANOS_PER_MINUTE = TimeUnit.MINUTES.toNanos(1); + public static final long NANOS_PER_SECOND = TimeUnit.SECONDS.toNanos(1); + public static final long NANOS_PER_MILLISECOND = TimeUnit.MILLISECONDS.toNanos(1); + + /** + * @param binaryTimeStampValue + * hive, impala timestamp values with nanoseconds precision + * are stored in parquet Binary as INT96 + * + * @return the number of milliseconds since January 1, 1970, 00:00:00 GMT + * represented by @param binaryTimeStampValue . + */ + public static long getDateTimeValueFromBinary(Binary binaryTimeStampValue) { + NanoTime nt = NanoTime.fromBinary(binaryTimeStampValue); + int julianDay = nt.getJulianDay(); + long nanosOfDay = nt.getTimeOfDayNanos(); + return DateTimeUtils.fromJulianDay(julianDay-0.5d) + nanosOfDay/NANOS_PER_MILLISECOND; --- End diff -- 1. I would recommend not using Joda. Do the calculations directly, like in ConvertFromImpalaTimestamp. Joda uses non-standard, hence confusing, terminology. What Joda calls and uses as JulianDay, is actually Julian Date. Seems like you have identified this discrepancy and adjusted for it by subtracting 0.5 from _julianDay_. Note: (I guess you have already figured this out) : The actual code and the Joda code in the comment, in ConvertFromImpalaTimestamp, are inconsistent. Took me a day to figure out the reason behind this ! A bug should be opened to delete the comment. 2. Can you please also leave a comment stating that 2440588 is the JDN for the Unix Epoch. 3. Please leave a comment stating that the order of the calls to get _julianDay_ and _nanosOfDay_ matters. You can do this by just stating how timestamps are stored in INT96 i.e 32-bit JDN followed by 64-bit nanosOfDay. 4. Consistent(single or none) spacing for binary operators (+-/) used here would be nice. Single spacing would be preferable.
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---