Looking for a way to get the seconds until #post.created_at date time with timezone.
Using DateTime.now.in_time_zone to get the current date and time. I can use the ruby time helpers but I really only need the seconds.
There is distance_of_time_in_words but no distance_of_time_in_seconds helper
how would you calculate seconds away (left until) a certain #post.created_at?
A simple
#post.created_at - Time.now
..will give you the seconds. You need not have to worry about Time Zones, because Rails will be handling the time zones (since both are objects with time zone details with it), before calculating the difference.
(Time.now.in_time_zone - #post.created_at.in_time_zone).to_i
Will return the difference in seconds.
Related
Is there any way to know the time taken for each action to finish in Robot Framework???
Like For example, I want to rotate screen 90 degrees 10 times, how to time it or how to average the time taken by these actions??
The simplest solution is to get the current time, run your keyword or keywords, then get the current time again, Then, subtract the starting time from the ending time.
Robot framework provides a DateTime module that has functions to support this. For example, Get current date can return the current date and time. Subtract date from date can return a timedelta which can be formatted to days, hours, minutes, seconds, and milliseconds.
You can see it in your report.
http://robotframework.org/QuickStartGuide/report.html
Elapsed Time: 00:00:00.284
It is also available at Keyword Level in the Test Execution Log.
${date1} = Get Current Date
TestCase_To_Rotate_Screen_10_Times
${date2} = Get Current Date
${actiontime} = Subtract Date From Date ${date2} ${date1}
I've found a few answers to questions similar to this elsewhere, except with adding or subtracting two times to get a duration, however, I haven't been able to figure it out enough to meet what I want.
I'm trying to get the time that I woke up using the time that I went to bed and the duration. I've tried doing [Time] + [Duration], however when I do that I get a value like 10060:25:00. I've also tried adding the hour value of the duration and the hour value of the time and dividing by 24, but that didn't work either. I did figure out the minutes though, all I did was =MOD([Time minute value]+[Duration minute value],60).
So to clarify, I just need to find the hour value now.
I am not exactly sure if this answers your question, but I think it is very similar. And I apologise in advance for an unnecessarily complicated description.
Sorry I didn't have time to provide a shorter answer.
I wanted to create a run sheet for a workshop with session durations.
I have a start time, and each session has a duration. I can then calculate start time for next session and cumulative duration of the sessions.
column label :> A || B || C || D
Heading label:> start_time || duration || hidden_duration || Elapsed
Number format:> date/time || number || duration ||duration
new start_time=previous_start_time+hidden_duration
hidden_duration=if(isblank(duration),"0:00:00","0:"&duration)
It seems time is particular about how it interprets a number. This is where the duration format fits in, as it formats correctly to add to time. However, a field formatted as a "duration number format", must then be entered as a duration. In other words, it is expected as 00:00:00.000 which is very particular. Or in fact, it appeared it at least needed 00:00 i.e. Hours and minutes separated by colon.
As I only had minutes, I didn't want to have to enter in this particular format all the time; and if I was to put 5 in the duration field, it was being interpreted as 5 milliseconds (or something). So I have used a simple number in the duration field and inserted it into a string in the hidden_duration field to form 0:duration. For example to add 5 into the minutes column of the hidden_duration entry it would be "0:"&5. The if(isblank(),...test was necessary to avoid blank durations voiding all the way down the column. i.e. If duration was blank, add 00:00:00 time to the start_time.
Start_time Duration Hidden_duration Elapsed
08:30:00 15 =if(isblank(B2),"0:00:00","0:"&B2&":00") =C2
=A2+C2 5 =if(isblank(B3),"0:00:00","0:"&B3&":00") =D2+C3
Drag the second row down to repeat however many entries you will have.
Don't forget to make the appropriate columns the correct number formats.
Also, you can modify the duration formats using Format | Number | More formats| Custom Number Formats and removing the unwanted display fields (such as seconds).
Then, I also made some conditional formatting rules, so that if a duration was blank, the Elapsed and time cells were white text on white background so they looked blank.
For your application you could do the same but have separate hours and minutes columns to make for easy data entry, both being used in the "hidden_duration" formula.
I hope I have helped here, as I found your question, trying to do the same and Googling an answer, but then ended up experimenting and discovering some new things myself.
Someone more knowledgable may be able to correct my entry or make more efficient. {Or at least explain more efficiently (; }
=HOUR(B2-A2)+(MINUTE(B2-A2)/60)
Basically, being B2 the end time and A2 the start time, you subtract B2-A2 and get the hour from the subtraction. Then you do the same and get the amount of minutes. After you have both, you sum the amount of hours with the amount of minutes divided by 60 (to get it in hours).
Don't forget to use the 24-hour format (i.e. 10:00 or 22:00).
I have an ActiveSuppport::TimeWithZone object and I want to find out how many minutes after 11 AM on that day it is. So, for example, if the time is 11:47 AM, I want the answer to be 47.
Is there a way in Ruby/Rails to do this.
Thanks!
Subtracting one Time object from another gives the difference in seconds. Just divide by 60 to get minutes.
(mytime - Time.parse('11 AM')) / 60
Given an NSTimeInterval representing a period of time, how do I create a human-readable string that expresses that time period in a way that respects i18N?
For example, if the NSTimeInterval is equal to 10823.23435 seconds, then some reasonable ways of rendering that as a string for those in the US might be:
3:23
3 hours, 23 seconds
etc.
(I.e., stuff you'd see on a stopwatch.)
Presumably other locales might use different renderings.
I'm aware of NSDateFormatter and NSNumberFormatter, but it's not clear to me if or how to use one of these for this problem.
I'm also aware of FormatterKit, but that only does relative time periods (e.g., "3 minutes ago"). I'm looking for absolute time periods.
It is trivial to cook up my own locale-specific solution, but has this problem been solved properly already?
Thanks.
For iOS 8 there are NSDateComponentsFormatter & NSDateIntervalFormatter, they may work for your application.
Docs are lacking see NSHipster: NSFormatter
and
Foundation/NSDateIntervalFormatter.h
As the subject asks; do UNIX timestamps change in each timezone?
For example, if I sent a request to another email the other side of the world saying, "Send out an email when the time is 1397484936", would the other server's timestamp be 12 hours behind my own?
The definition of UNIX timestamp is time zone independent. The UNIX timestamp is the number of seconds (or milliseconds) elapsed since an absolute point in time, midnight of Jan 1 1970 in UTC time. (UTC is Greenwich Mean Time without Daylight Savings time adjustments.)
Regardless of your time zone, the UNIX timestamp represents a moment that is the same everywhere. Of course you can convert back and forth to a local time zone representation (time 1397484936 is such-and-such local time in New York, or some other local time in Djakarta) if you want.
The article at http://en.wikipedia.org/wiki/Unix_time is pretty impressive if you'd like a longer read.
Unix time is defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970. So the answer is no
Unix timestamps do not change accross timezones, they are created for the purpose of having a standard time across globe.
NOTE:-
Timestamps are calculated on the basis of current time in the computer thus do not rely on them until and unless you are very sure about the time settings in the participating machines.
Someone stated that "UTC is Greenwich Mean Time without Daylight Savings time adjustments." This is simply untrue. GMT does not have Dayllight Savings Time. GMT is measured in Greenwich, England (at the Naval Obeservatory) [0 longitude, but not 0 lattitude]. UTC is measured at the equator [0 longitude and 0 lattitude - which happens to lie in the ocean off the cost of Africa].
What difference does it make? It doesn't make a difference in terms of "what time of day is it?" It does, however, make a difference in terms of calculating a year. Now you'd think a year would be measured based upon the location of the center (the core) of the earth, right? When the earth's core is back in the same location it was ~365 days ago, it has been a year. It isn't measured that way. It is measured by a specific location on the earth getting back to the same location (relative to the sun) that it was ~365 days ago. But the period of a day and a year don't divide evenly. Once the earth is back to about where it was a year ago, the earth isn't facing the same direction it was last year, so that spot on the earth isn't facing the same direction it was a year ago. Being further north, Greenwich isn't going to get back to the same spot (relative to the sun) that it was last year at the same time that 0 Lat / 0 Long is. So if you base the definition on Greenwith vs. 0/0, you get a, albeit slightly, different answer to the question "how many days are in a year". To put it another way, when a given spot on the earth gets back to where it was a year ago (relative to the Sun), the core of the earth isn't in the same spot it was a year ago, so what spot you pick matters because the core of the earth is going to be in a different spot (relative to the sun) than it was one year ago, if you pick a different spot on the earth.
Neither UTC nor GMT have daylight savings time. Europe/London time, the timezone that Greenwich resides in, does. But GMT does not. GMT is, what Americans would call a "Standard Time" - i.e. without DST.
Getting back to the question, Epoch time doesn't technically have a timezone. It is based on a particular point in time, which just so happens to line up to an "even" UTC time (at the exact beginning of a year and a decade, etc.). If that concept doesn't fit well in your brain, and if it helps to think of Epoch time as being in UTC, go right ahead. You're in good company and in the grand scheme of things, it really doesn't matter. You ever see those law suits where somoene is awarded $1. It's kind of a "you're right, but it doesn't really matter" type of verdict. If someone sued you for saying Epoch time is in the UTC timezone, they would win $1. That wouldn't buy them a cup of coffee at any Starbucks in any timezone on the planet.
IF both computers are set up correctly with their clocks set for the correct timezone and UTC values, they should return the same value.
Of course that's a big IF. There's almost certain to be a difference of at least a second, more often minutes between the time reported by two computers. And many computers are set up to have incorrect timezone settings, and will report their local time when asked a timestamp rather than UTC.
And in that lies the difference between theory and practice. In theory it's all the same, in practice you should not rely on it.
No, epoch timestamp should not change, because it has a fixed timezone which is UTC.
If you want to use a time object in other time zone, just look it up in libraries of the language you use, but do NOT try to add/substract a couple of hours from epoch timestamp and assume it's in another time zone, which will make things very confusing to other people, especially when you expose it in your API.
If you use C++, I recommend this library. I heard it will soon be added into standard library.
For all, I understand sometimes time object is hard to deal with and it looks easier to add/substruct on epoch timestamp. Please don't do it and do not persuade others to do it. A time object is much easier once you get used to it and can take care of time zone conversion easily without messing up with historical time zone changes due to politics/law etc...