I am working on Hbase database and using apache Phoenix to access Hbase using normal SQL queries.
I have two columns in table which holds the current UTC timestamp in varchar and Date. after loading some data and when I query back Hbase I am getting strange results for event timestamp column which is of Date type.
Event UTC (Date) :2017-01-13 16:36:59.0
Event UTC (varchar):2017-01-13 21:36:59
above two values should be identical but for each record when querying back Event UTC ( Date) column giving me wrong result i.e exactly 5 hours behind.
I dont know from where this problem is coming .I am not saving any Timezone info and I am aware that Java Util or SQL timestamp doesnt store any time zone info, But really confused with the result set data when running a query. Please Help me in resolving this issue
Most likely it is because of the client's local time zone.
From official docs
Timestamp type:
the internal representation is based on a number of milliseconds since the epoch (which is based on a time in GMT), while java.sql.Timestamp will format timestamps based on the client's local time zone.
Related
Using DBeaver we are trying to execute the following query.
UPDATE listing SET ScheduledTime='2019-01-09 15:14:51.0', Status='SCHEDULED' where ID=108
after successful execution, we can see the ScheduledTime column as '2019-01-09 20:44:51' in DB. Why there is a time mismatch and how we can solve it? Assistance in this matter is greatly appreciated.
You use different timezone setting when you store and when you view the data. As mysql documentation on timestamp says:
MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. (This does not occur for other types such as DATETIME.) By default, the current time zone for each connection is the server's time. The time zone can be set on a per-connection basis.
Mysql documentation describes how to view and set timezone here
I am using DATETIME field to store my dates in MySQL. Without any timezone specified directly (there is just a datetime column)
But when timezone was changed on server MySQL updated all datetime columns according to new timezone.
Actually switching to EDT was the reason.
I don't need to recalculate my dates automatically - just want to store specific dates in it.
So even if tz changed manually to UTC from EST date should be same (from characters POV) if it was 2016-01-01 18:55 it should be same in any new tz..
I did not run any scripts\queries to update dates.
So it was performed either by MySQL itself or by server.
Need advice what I need to check to find and disable such feature.
Make sure you are using DATETIME and not TIMESTAMP
[From the MySQL documentation][1]:
MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. (This does not occur for other types such as DATETIME.)
You should also review this post (Duplicate):
Will changing a MySQL timezone change values of DateTime fields in a database?
I am sorry for the mess I brought
Just extended my query to grab some old dates - and it looks unchanged
So error defenetly in my code..
Anyway - thanks for your help
So ... I inserted an entry into a table with time stamps. The entry got inserted perfectly.
But the time stamp that got inserted was :
'2015-06-22 10:32:47'
I checked the time on the server:
Tue Jun 23 01:35:41 IST 2015
And inside mysql :
select now();
2015-06-23 01:33:57
So I check the time in irb.
time = Time.now
=> 2015-06-23 01:36:41 +0530
time.zone
=> "IST"
The time zone is right .. but I dont know where is it picking up the time from? I cant figure out where is it picking up 10:32 from ? and how do I fix it ?
Appreciate all your help.
Rails by design converts a datetime into UTC before inserting the value into the database.
This is because, in general, it's not possible to easily represent timezones in the database. Moreover, this approach guarantees the date will be consistent and/or easy to query in the following cases:
if the server time zone changes or you change server with a different timezone
if you want to query the date using a different timezone
if you want to format the date with different time zones depending on the user or other configs
You can customize the default timezone for the app, so that Rails will properly compute the correct difference to UTC when the value is stored into the database. However, you cannot change this behavior: times will always be converted into UTC before being stored in the database.
Generally speaking, if you properly use the Rails date transformation helpers, this shouldn't cause any issue.
For instance, if you want to query all the records where the time is past, the following query
Record.where('some_date < ?', Time.current)
will properly convert Time.current from your app timezone into UTC, and query the database accordingly.
I am running MYSQL 4.1 database that stores call center data for our offices that operate in Europe.
My MYSQL database sits on a Windows 2003 server that's has its time zone set to Central European Time, which automatically adjusts to day light savings.
I want to able to produce a report that shows the log date and time in the correct time zone to our customers in Europe.
My database stores the log date / time of the call as a unix time stamp. So therefore the dates stored as UTC. I found MYSQL function that can easily adjust the log date time to a time zone of your choice.
It's called CONVERT_TZ. (More info:http://dev.mysql.com/doc/refman/5.1/en/date-and-time-functions.html#function_convert-tz)
Example: SELECT CONVERT_TZ('2004-01-01 12:00:00','UTC','CET');
I tried to apply this to call that was logged on 01-06-2013 22:12
CONVERT_TZ(FROM_UNIXTIME(o.logdatex), 'UTC','CET') 'CET_L_DATETIME'
(logdatex is the unxtimestamp for when the call was logged)
To my confusion the statement returned - 2013-06-02 00:12:56.
I wanted to see what was returned when I just selected FROM_UNIXTIME(o.logdatex)
It returned the correct time! 2013-06-01 22:12:56 (This call was logged from our Amsterdam office)
My question is, does the FROM_UNIXTIME function automatically adjust the time from UTC according to what the time zone MYSQL server is set to? I cannot find any documentation that says it does.
My assumption this is because when you do FROM_UNIXTIME(o.logdatex) you convert from UTC to timezone of your server.
And now you date is not in UTC timezone. So in CONVERT_TZ(FROM_UNIXTIME(o.logdatex), 'UTC','CET') you don't convert from 'UTC' but from timezone of your server so you get a strange result for you.
Try to select FROM_UNIXTIME(o.logdatex) as a separate field in your query and compare results.
Say I have multiple servers in multiple locations and I want to use MySQL's datetime type for the field date and I always want to have the field date have the UTC timestamp so I would execute a UTC_TIMESTAMP() when I add it to the database. Now say I want to have MySQL output the UNIX TIMESTAMP for it.
When I do this on Server A I get the string "2009-06-17 12:00:00" doing the UNIX_TIMESTAMP(STRING) on it gives me the number 1245240000 back. Which is 2009-06-17 12:00:00 in UTC time. Now I do the same thing on Server B.
I get the same string back since its the UTC string but when executing UNIX_TIMESTAMP(STRING) again I get back the wrong number back 1245232800 which is the UTC +2 time. How do I get around this? Should I do the convertion from string to timestamp on the PHP side?
G'day,
I'll ask the obvious here, did you check the date and time on both machines?
Edit: ... and the MySQL timezone was the same on both machines?
Update: Ok. The problem is in the fact that the timestamp string being passed into UNIX_TIMESTAMP is interpreted to be a value in the current timezone which is then converted back to UTC so, because you're in MEZ, two hours is subtracted to return it back to UTC so 7200 is subtracted from your timestamp when it is converted back to a Unix timestring.
Hence, the variation you see when using UNIX_TIMESTAMP() to convert is back to a Unix Epoch timestring.
BTW Shouldn't you be using a TIMESTAMP type for storing off your UTC_TIMESTAMPs instead of DATETIME type?
Update: Decoupling presentation time from stored time is definitely the way to go. You can then reuse the same data all around the world and only have to convert to and from local time when you are presenting the data to a user.
If you don't do this then you are going to have to store off the timezone when the timestamp was made and then go into all sorts of complicated permutations of having to work out if
the local timezone was in daylight saving time when it was stored,
what the difference is between the timezone at the time that the data was stored and the timezone where the data is to be presented.
Leaving it all storeed as UTC gets rid of that.
Most users won't be that happy if they have to work out the local time themselves based on the UTC time returned so systems usually convert to current local time for the user.
This is of course if the user wants the data expressed in local time which is usually the case. The only widely used system I can think of, off the top of my head, that stores and presents its data in UTC is system for air traffic control and flight plan management which are always kept in UTC (or ZULU time to be more precise).
HTH
cheers,
Have you tried doing this?
Execute this instructions together.
SET time_zone = 'UTC';
SELECT FROM_UNIXTIME(0), UNIX_TIMESTAMP('2009-06-17 12:00:00');
// 1970-01-01 00:00:00 1245240000
They only affect the client session, not the server configuration.