We have a build that runs all the ruby files including unit_tests.
Build is configured at UTC time and our database inserts records based on CST timezone because config.time_zone property in application.rb is set to CST timezone.
My unit tests had start_date: 50.days.ago and when i ran build it'll pass anytime during day before 7 PM. After 7 PM per build UTC time its next day. I mean if i start build at 7:10PM, build will show 12:10 AM and it'll fail.
I changed start_date: 50.days.ago.to_date and it doesnt fail now.
Can someone explain me why it worked using to_date?
When you do
50.days.ago.to_date.class it returns #ActiveSupport::TimeWithZone
but when you do
50.days.ago.class it returns #Date
they feel the same but they are really different objects
Related
I am trying to see all of my test runs from a specific Date/Time.
I can simply put a date in there and see all of the runs since a specific date, but I would like this to be more precise. I want to get all test runs with a completed date of greater than MM/dd/yyyy HH:mm:ss
What is the syntax for this? I tried putting
#12/12/2019 11:40:34AM#
in the box and it worked sort of. It shows all test runs for 12/12, but the time doesn't do much. If I change the AM to PM, all of the AM runs disappear, but changing the actual time value does nothing
What do I need to put in the value field to see runs by date/time?
Please try to type the UTC time. For example, my time zone is UTC+08:00, if I need to filter "Completed Date > 2019-06-14 1:49:53 PM" for test runs, I would type "2019-06-14T05:49:53". Check the screenshot below:
We have tried using IST minus the difference between IST and CST, so that we can get CST time (the SUT's time), but it won't work when daylight saving time comes. Kindly someone help on this to get the SUT time.
You can't directly take the time zone from a SUT. There are a few methods to do what you're trying to accomplish:
1. Screen capture the time on the SUT.
Using OCR, isolate the searchRectangle to the system's clock. Then readtext() and save the read text to a variable myTime.
2. Remote commands (mobile SUTs only).
You can send a remote command to a SUT using the Eggplant function ExecuteRemoteCommand(). From Eggplant's documentation:
"On Android, ExecuteRemoteCommand runs as a shell command on the
actual phone.
On iOS, ExecuteRemoteCommand runs the command as
JavaScript, making calls to the Apple UIAutomation API."
You can save the output of these commands to a variable, so on an Android SUT it would be:
set SUT_time to ExecuteRemoteCommand(date)
SUT_time will now represent the time in the format Mon Jul 31 21:09:28 CDT 2017.
3. Math!
Given your current system's date and time, you should always be able to calculate the time of any given timezone. Currently, that would work out as:
set SUT_time to the date minus 10 hours 30 minutes
To make this compatible with daylight saving's time, you'll have to use an if statement. That might look something like this:
set CST to the date minus 10 hours 30 minutes
if CST is between "Mar 11" and "Nov 4" then
add 1 hour to CST
end if
We have a scheduler that got triggered at 12 AM everyday. It work perfectly until I do not change timezone such that it skips next subsequent calls.
Example, Current time and Date is 4 PM of 10th February, I change timezone such that new time is 12:30 AM of 11th February.
Result:
No trigger happens after that.
Expected:
Skipping Trigger on 12:00 AM on 11th February is acceptable but it should execute all subsequent schedules at 12 AM every day.
I have not included any misfire instruction. Please help me.
In some versions of crontab you can set the time zone for when the job should run like:
TZ=GMT
30 11 * * *
This would run at 11:30am GMT every day, even if the server was in some other time zone.
Even though Jenkins scheduling is based on cron, it doesn't seem to have this specific syntax. Is there some other way to do this in Jenkins?
Thanks
As Michael mentioned in his answer, this functionality was added. Here's an example:
TZ=Europe/Kiev
0 1 * * 5
That would run at 1:00 AM Ukraine time, once a week on Friday.
To get the names of time zones to use, you can use the column marked "TZ database name" in https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
Looks like they added this in 2.60.2.
There's no way to do this in Jenkins. You could trigger the builds by calling a URL from cron though.
Edit: This has since been added; see the other answers.
I have a rails application and I store all time in UTC in the database for TimeZone differences' purposes. I also expire a record instead of deleting it by setting "effective_end_date" field in the table to current time. Then I use named scope as follows in the model:
named_scope :valid, :conditions => ['(effective_end_date IS NULL OR effective_end_date > ?)
AND (effective_start_date IS NULL OR effective_start_date < ?) ',Time.zone.now.gmtime, Time.zone.now.gmtime]
This seems to work fine on my Mac dev machine but once I move to production there seems to be discrepancy between the system time and the time which I'm not sure why!! Typing "date" command in Linux seems to give the right time. Looking at the production log file below:
sms parser(inparser) daemon is still running at Wed Jun 03 22:38:36 -0700 2009.
[4;35;1mUltrasmsin Load (0.5ms)ESC[0m ESC[0mSELECT * FROM `smsin` WHERE ((effective_end_date IS NULL OR effective_end_date > '2009-06-04 05:28:32')
AND (effective_start_date IS NULL OR effective_start_date < '2009-06-04 05:28:32') )
This the generated query from the following lines of code:
ActiveRecord::Base.logger.info "sms parser(inparser) daemon is still running at #{Time.now}.\n"
nonConvertedMsgs = Ultrasmsin.valid.find(:all)
The first command time displayed from "Time.now" is correct but the second time (fetched from the named scope) seems to be wrong!! (off by 10 minutes)
This is really puzzling me as I would think Time.zone.now.gmtime would just convert hours and wouldn't touch the minutes but it seems that hours are converted ok to GM Time but the minutes are off by 10 minutes!
Any ideas?
On your Mac development machine, everything - DBMS, Rails, browser - is probably running in a single time zone, and it is your time zone.
On your production machine, it is likely that something is running in a different time zone. How a DBMS handles differences between client time zone and the database time zone varies, depending on the DBMS. Some operate in the DBMS's time zone - whatever time zone was set in its environment when it was started. Some take into account the client's time zone. Sometimes, there is no easy way to find the client's time zone.
In general, time zones in the modern world are multiples of 1 hour off UTC. There are exceptions - both India (+05:30) and Newfoundland (-04:30) are a multiple of half an hour off UTC, and Nepal is on (+05:45). However, a malformed time zone setting could throw things off.
Also remember that the clocks on the client and server may not be synchronized to an atomic clock somewhere, so a ten minute drift could be due to the lack of SNTP (NTP) service on the machine.