Thought about that myself based on my prior (bad) experience when tried to
working with timezones in Hive (functionality pretty much doesn't exists)
That shouldn't be the case here though, here's why:
in Oracle [timestamp with timezone] can be adjusted when sent/displayed on
the client based on client's settings. This may be also relevant if the
timestamp in question would fall onto client's daily saving time period.
This behaviour would make sense to me, however:
• this is server, not client settings we're talking about here
• the server and client do reside in the same timezone anyway, which is
currently GMT [UTC]
• while we observe the daily saving here [Dublin] the time in question
("1970-01-01 00:00:00") is not in that period, neither the time I'm sending
the query (now).
Based on all above, I don't see the reason the time gets shifted by one
hour, but I realise the issue might be down to the general problems in
Hive' implementation of timezones…
On Fri, Oct 31, 2014 at 12:26 PM, Nitin Pawar <nitinpawar...@gmail.com>
wrote:
> In hive from_unixtime is returned from the timezone which you belong to
> "From document : from_unixtime(bigint unixtime[, string format]) :
> Converts the number of seconds from unix epoch (1970-01-01 00:00:00 UTC) to
> a string representing the timestamp of that moment in the current system
> time zone in the format of "1970-01-01 00:00:00".
>
> if possible can you also check by changing the timezone to UTC on your
> machine?
>
>>
>> On Fri, Oct 31, 2014 at 12:00 PM, Maciek <mac...@sonra.io> wrote:
>>
>>> Any reason why
>>>
>>> select from_unixtime(0) t0 FROM …
>>>
>>> gives
>>>
>>> 1970-01-01 01:00:00
>>>
>>> ?
>>>
>>> By all available definitions (epoch, from_unixtime etc..) I would expect
>>> it to be 1970-01-01 00:00:00…?
>>>
>>
