I'm working with a Dataset which gives me a Time Variable for Objects, just like the created_at. The value tho is :
1398037671
Is this a special kind of encoding Timestamps or am i missing something ?
I guess it is "seconds since the Epoch" timestamp
Time.at(1398037671)
2014-04-21 01:47:51 +0200
http://www.ruby-doc.org/core-2.1.1/Time.html#method-c-at
That's a Unix timestamp. That specific timestamp represents 04 / 20 / 14 # 11:47:51pm UTC
You can find out more about them here: http://www.unixtimestamp.com/index.php and at good old wikipedia here: http://en.wikipedia.org/wiki/Unix_time
In Ruby, you can generate a Unix timestamp with Time.now.to_i (or obviously any other time if you don't want the timestamp for now).
Related
I'm using Rails. I've stored a count by month in a postgres db as a hash using hstore.
The stored hash is formatted as follows:
{"2017-03-01 00:00:00 UTC"=>"10", "2017-04-01 00:00:00 UTC"=>"3"}
I'm struggling to find a great way to retrieve specific month counts from this hash due to the date format used for the key.
QUESTION
What is the best way to format a string to match the current hash key date format?
For example for March in the Hash the key is "2017-03-01 00:00:00 UTC"
However, a new DateTime for March 1 2017 is formatted as "2017-03-01T00:00:00+00:00"
Or is it best to change the format of how I am storing the hash in the first place?
If you need a timestamp in a specific format, the standard tool to use is DateTime#strftime (all the time-ish classes will have a strftime method and they all behave the same). In your case:
some_datetime.utc.strftime('%Y-%m-%d %H:%M:%S %Z')
And hooking that up to ActiveRecord:
Model.where('your_hstore -> :key', :key => some_datetime.utc.strftime('%Y-%m-%d %H:%M:%S %Z'))
Or:
Model.where('your_hstore -> ?', some_datetime.utc.strftime('%Y-%m-%d %H:%M:%S %Z'))
%Z should be the "Time zone abbreviation name" and for me it produces strings like 'UTC', 'PDT', ... If your strftime (which almost certainly is just a wrapper around the system's libc version of strftime) doesn't produce the strings that you want then you have some options:
Drop the timezone completely if it will always be UTC. Then the keys would look like 2017-03-01 00:00:00 and you'd use '%Y-%m-%d %H:%M:%S' as your strftime format string.
If they keys are actually just dates as they appear to be, then use dates and drop the time-of-day. Then your keys would look like 2017-03-01, you'd use Date instances in Ruby rather than DateTimes, and you'd say some_date.strftime('%Y-%m-%d') or some_date.iso8601 in Ruby to get your hstore keys.
If you are using non-UTC timezones, then convert everything to UTC and go with 1 or 2.
If you don't want any of the above, switch to numeric timezone offsets (2017-05-10 18:05:57 +0000, 2017-05-10 18:06:48 +00:00, ...) and use %z, %:z, or %::z in the strftime format string (see the docs for difference between these three).
These of course require reworking any data you already have in the database but it is best to get the out of the way sooner rather than later.
Why isn't Time.current equal to its parsed equivalent?
current = Time.current
# Wed, 16 Sep 2015 17:10:56 CEST +02:00
parsed = Time.zone.parse('16 Sep 2015 17:10:56')
# Wed, 16 Sep 2015 17:10:56 CEST +02:00
current == parsed
# false <= What ?!
current.to_i == parsed.to_i
# true
Ticket.create(datetime: current)
# ...
Ticket.find_by_datetime(parsed)
# nil <= Why ?!
I'm actually having trouble with this in a Ruby on Rails application where I try to find a record based on a datetime attribute that has been parsed, like shown on the last lines.
I really don't get it. Time zones are the same, times are the same down to seconds. What's happening here?
Moreover, how should I proceed to find a record based on a parsed datetime?
They should not be the same:
current.to_f #=> 1442417032.6567826
parsed.to_f #=> 1442417032.0
When parsing, you miss milliseconds.
Thanks everyone for the help. I hope you don't mind but since pieces of the final answer are scattered across multiple answers I will answer my own question building on what you all said.
So as for why the dates are different, it's because of the milliseconds missing in the parsed datetime. As #dimakura mentioned.
current.to_f #=> 1442417032.6567826
parsed.to_f #=> 1442417032.0
Then the answer about how could we fetch the Ticket record based a the parsed datetime.
First it's important to know this will be relevant only for PostgreSQL (my case) or other databases that actually store milliseconds. Thanks to #sjagr for mentioning this.
So we have to query for a range from parsed to parsed + 1 second, like #Stefan explained:
Ticket.where(datetime: parsed...parsed+1).first
And if we have control on the Ticket creation, we could also remove the millisecond precision before saving the the database. Thanks to #sjagr for providing an easy way to do that.
current = Time.current
Ticket.create(datetime: current.change(usec: 0))
Thanks everyone !
It's because they are not equal, they differ by parts of the second. What you see in the console is the result of inspect method called on those dates, which by default, drop any sub-second parts.
I'm accessing the Evernote API via the evernote gem for ruby on rails, and I'm storing the objects (notebooks, tags, notes, etc.) in a Postgresql database.
Evernote returns timestamps that look like this:
1344141917000
1344141967000
1344138641000
The evernote api documentation says this is the number of milliseconds that have passed since the base time of January 1, 1970, 00:00:00 GMT
I've conducted the following exercise in the rails console in an attempt to reconstruct the date.
evernote_timestamp_base = Time.gm(1970,01,01,00,00,00)
=> 1970-01-01 00:00:00 UTC
evernote_timestamp_base + 1344138641000
=> 44564-01-22 04:43:20 UTC
Definitely not right. But chopping those last three zeros off yields the right date:
evernote_timestamp_base + 1344138641
=> 2012-08-05 03:50:41 UTC
Am I missing something here? What's the deal with those last three zeros? Will I have to parse and chop the evernote timstamp values and then add them to the 1970 base, or is there an easier way?
Also, what's the best Postgresql data type for storing these values?
Thanks in advance for your help.
To do this in Ruby, use Time.at. You'll need to divide by 1000 since Evernote timestamps are in millseconds and Ruby/Unix timestamps are in seconds.
createdNote = noteStore.createNote(authToken, note)
createTime = Time.at(createdNote.created / 1000);
puts "Note was created at #{createTime}"
In postgresql you could use a timestamp [with|without] time zone as the type for the column.
The unix timestamp is defined as the number of seconds since January 1, 1970, 00:00:00 GMT which is what Ruby and many other systems use and or support. PostgreSQL can do the conversion for you to. Just pass the value in seconds to the to_timestamp function.
SELECT to_timestamp(1344138641000/1000.0)
To convert it back use
SELECT EXTRACT(EPOCH FROM col)
I am searching to parse this timestamp
2011-05-18T0702:19Z0088
The first part of the string ("2011-05-18T0702:19Z") look like a ISO 8601 UTC Timestamp, but i don't understand last numbers "0088"
Did someone can tell me more about this format ?
William
Actually it doesn't make sense, since Z is indication of UTC time, after which no symbols are allowed in datetime. So it's actually some invalid format.
If you sure that 'Z' corresponds to UTC you can ignore symbols after it, or, better, contact source of this format and ask them for fix.
Now, I also notices there is one more error in format, there is no colon between hours and minutes:
2011-05-18T 0702 :19Z0088
Sorry if that question sounds strange, but I'm diving into Rails and I'm still learning the jargon. Basically, I'm trying to create a single-pass query that uses the value of one of the model's attributes in a calculation in the query (assuming that's even possible).
I have a Tournament model that has a start_date attribute that is a DateTime object. I'm trying to create a query that returns all the Tournaments that have a start_date no older than 1 hour + the length of the tournament, or put another way, all tournaments that haven't yet started or have started, but haven't ended longer than an hour ago. My current query, which doesn't work, looks like this...
validTourneys = Tournament.where("start_date > (? - duration_in_mins)", (DateTime.now.utc - 1.hour))
where duration_in_mins is an integer attribute of the Tournament model, but this query doesn't work and it seems to be returning all the Tournaments all the time. I'd like to include duration_in_mins in the (DateTime.now.utc - 1.hour) part of the calculation, but I don't know how to reference it, which is why I included it in the string part of the query, hoping that would work. Am I at least on the right track?
I should mention I'm using SQLite for development and PostgreSQL for production.
Thanks for your wisdom!
The problem is that if you subtract minutes from a DateTime object, you are not subtracting minutes but days.
# This works as expected
dt = DateTime.now # Thu, 28 Apr 2011 09:55:14 +0900
an_hour_ago = dt - 1.hour # Thu, 28 Apr 2011 08:55:14 +0900
# But, this does not...
two_hours_in_minutes = 120
two_hours_ago = dt - two_hours_in_minutes # Wed, 29 Dec 2010 09:55:14 +0900
In the last example 120 days are subtracted instead of minutes. This is probably also happening in your query. You have to convert duration_in_minutes to days and then subtract.
I don't know enough about SQL to answer your question directly (I think this will probably also depend on what database you're using, so you might want to mention that).
Have you considered, though, having start_date and end_date as DateTime columns instead of start_date and duration_in_mins? If this is going to be a common query, that would certainly make it more performant, as well as making your code easier to read and understand.
This query will only work if your database is smart enough to know how to add (what I am assuming) is a DateTime and and integer. And I can't think of a database that will do that correctly the way you have it coded. No database will assume minutes. Some might do ticks, seconds, or days.
This part of the calculation
(? - duration_in_mins)
is going to happen on the database, not in Ruby-land.