My server default timezone is +0400 (Moscow). All instance recording to DB in UTC format. IE: it user create item at 04-00 this is recorded as 00-00. When I'm trying to get
Item.last
I see the UTC raw time. When I'm asking
Item.last.created_at
I've get +0400 time. BUT! When I'm using std time functions like
Item.where('created_at > ?', Time.now.beginning_of_day)
it is making sql query
SELECT `items`.* FROM `items` WHERE (items.created_at > '2012-11-30 00:00:00')
instead of
SELECT `items`.* FROM `items` WHERE (items.created_at > '2012-11-29 20:00:00')
So i'm losing 4 hours. The little crunch is using in_time_zone:
Time.now.beginning_of_day.in_time_zone(-4)
But I's not a jedi way :D Any ideas?
I hope your users have some settings related to their time zones in their profiles. In this case you can do the following:
Time.use_zone(zone_of_current_user) do # like 'America/New_York'
#products = Product.where('created_at > ?', Time.zone.now.beginning_of_day)
end
This way you'll set the zone for the block.
Note the using of zone method of Time.
I think i've solved it:
Time.now.beginning_of_day.in_time_zone('UTC')
=> Thu, 29 Nov 2012 20:00:00 UTC +00:00
So this is relation what time in Moscow when day beginnings in UTC timezone :)
Related
I have a very simple code for a cron job that makes a date entry into an SQL DB:
$qry_cron_test = "INSERT INTO ".$tblprefix."cron_test SET
create_datetime = '".date("Y-d-m H:i:s")."'";
$rs_cron_test = $db -> Execute($qry_cron_test);
The problem is the following:
Between 1st and 12th of every month the date entry is like this - 2014-10-03 07:30:39, which is what i want.
However, when the current date is between 13th and the end of the month, the date entry looks like this - 0000-00-00 00:00:00. Then when 1st comes the entires are all ok again.
I tested this on couple of servers and also locally on Xampp always with the same result.
Any suggestions? What could be possibly wrong?
You have month and day the wrong way around.
$qry_cron_test = "INSERT INTO ".$tblprefix."cron_test SET
create_datetime = '".date("Y-m-d H:i:s")."'";
$rs_cron_test = $db -> Execute($qry_cron_test);
date("Y-m-d H:i:s")
I recommend that, unless you need milisecond information, you always store date information in Unix Timestamp. It is lighter to store, since it is only a integer value, is faster to retrieve and is universal, since it is always based on UTC.
Specially in PHP, converting date information to (time() and strtotime) and from (date()) a unix timestamp is pretty easy. This way no matter where your user is, you can always show correct information in local time with almost no effort.
Wouldn't it be simpler to just do this:
insert into cron_test
create_datetime
values
(current_timestamp)
I'm using JDBC to add some rows to my DB and they have a date aspect to it.
The GMT String for the date I'm adding in the commit is
11 Jan 2014 05:00:00 GMT
but when I get it back I'm getting this:
11 Jan 2014 04:00:00 GMT
I'm 1 hour ahead of my server and this might be part of the problem. I tried using datetime and timestamp but none of these solved my problem.
my JDBC query looks like this: (it's in Scala)
val statement = connection.prepareStatement("INSERT INTO `listings`(`track_id`, `date`, `position`) VALUES (?,?,?)");
statement.setInt(1, trackId);
statement.setDate(2,trackListing.date);
statement.setInt(3, trackListing.position);
statement.execute();
Is there any way to avoid this problem?
Turns out that by changing setDate and getDate to setTimestamp and getTimestamp I could fix it. I ended up just wrapping the timestamps to dates to maintain compatiblity, using:
new java.sql.Date(rs.getTimestamp("date").getTime());
Hope this helps someone else with the same problem in the future.
I experienced a problem importing dates into MySQL. I boiled it down to this ...
select from_unixtime(unix_timestamp(str_to_date('201201', '%Y%m')))
It reports...
2011-12-31 00:00:00
To make it return the original date, is there something I need to set up with MYSQL, or do I just fiddle it and add on one day or something?
I'm in the GMT time zone.
A search returned some very old bugs about this and other posts says it was how it is supposed to happen, but I didnt understand what you are supposed to do about it
On 5.5.21 (OS X) i get 2012-01-01 00:00:00.
Try upgrading your server.
When I run it, SELECT STR_TO_DATE('201201', '%Y%m') returns the invalid date 2012-01-00 (January 0th?!), so I'm not altogether surprised that round-tripping that through UNIX_TIMESTAMP() and FROM_UNIXTIME() ends up messing it up. Try adding a day to make it a real date (2012-01-01) first.
Consider this. On my server, I convert a (UTC/GMT) timestring like this:
strtotime('Fri Feb 18 21:08:38 +0000 2011')
My server returns
1298063318
This is correct, since all unix timestamp converters that I tested, return the same. And vice versa, if I insert not the date but the timestamp, I get returned the timestring as given above. But if I convert the timestamp on my server:
date("Y-m-d H:i:s", 1298063318);
I get back a different date than expected (being 'Fri Feb 18 21:08:38 +0000 2011'):
2011-02-18 22:08:38
So it's off an hour. This is probably because my servers timezone is set at Europe/Paris, and it thus translates the timestamp into UTC/GTM + 1. But MySQL, ran on the same server and having the same timezone, gives me back another result:
SELECT FROM_UNIXTIME(1298063318) = 2011-02-18 22:08:15
In other words, it is off 18 seconds. Can somebody explain why?
For MySQL, a leap second correction is used for the date functions (MySQL Documentation). For PHP date functions, leap seconds are not taken into account. For that reason, you get now a 24 seconds difference.
You can try the following to solve your problem: http://pumka.net/2010/10/24/why-mysql-timestamp-is-24-seconds-different-from-php/
PS. 38 - 15 = 23
Either I'm being stupid or something's wrong here.
I have two SQL Servers, the one is on my local machine (local time +2 GMT) and the other is somewhere else (NOW() seems to return +8 GMT)and I access it through phpMyAdmin. I have a table that has a DATETIME column. I'm trying
to store the current GMT/UTC time and then display it again, still as GMT/UTC time.
Originally I stored DATE_SUB(NOW(), INTERVAL 8 HOUR) which worked just fine. However, then I read about UTC_TIMESTAMP() and liked it more, as it was shorter and the MySQL manual even said :
"The current time zone setting does not affect values displayed by functions
such as UTC_TIMESTAMP() or values in DATE, TIME, or DATETIME columns."
So perfect right? Except no.
Let's assume Current GMT is 2010-02-18 17:18:17 (I even double checked it with someone in Britain).
On my local (+2) server, I get the following results for the following queries:
SELECT NOW(); 2010-02-18 19:18:17
SELECT UTC_TIMESTAMP(); 2010-02-18 17:18:17
On my online server I get:
SELECT NOW(); 2010-02-19 01:18:17
SELECT UTC_TIMESTAMP(); 2010-02-19 07:18:17 (WHY?!)
Am I missing something?!
Probably because the clock are wrong on the online server?
Try running this:
SELECT ##system_time_zone, NOW(), UTC_TIMESTAMP()
and see which zone does it return and does it match the difference.