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
Related
Background
I am investigating different use cases of moment.js for a project but am stumped on the issue of daylight savings ending in the fall. Before asking my question, since I want to be clear and provide background for others who have similar questions, let me explain what I am doing and what found with spring daylight savings.
First, I am working with UTC timestamps and America/New_York timestamps. In the US, daylight savings in 2017 begins on March 12 at 2AM (skipping from 2:00:00AM to 3:00:00AM) and ends on November 5 at 2AM (reverting from 2:00:00AM to 1:00:00AM). Since I also always know the target time zone (America/New_York) that I need to convert to, I will not rely upon moment.js to detect my local time zone and instead explicitly specify the time zone I want.
During the spring when daylight savings goes into effect, the time zones that observe daylight savings, like America/New_York, jump forward an hour. moment.js handles this just fine.
For example, if I pass moment.js a UTC timestamp for the time one second before daylight savings goes into effect for America/New_York, it looks like this:
moment('2017-03-12T06:59:59Z').tz('America/New_York').format('YYYY/MM/DD hh:mm:ss a z')
The input above is taken as UTC because of the Z on my timestamp and I am explicitly setting the target timezone with .tz('America/New_York') so that it doesn't use local system time.
Alternatively using moment-timezone I can explicitly set the input time zone as UTC and set the output as America/New_York.
moment.tz('2017-03-12T06:59:59', 'UTC').tz('America/New_York').format('YYYY/MM/DD hh:mm:ss a z')
Either way, the result is 2017/03/12 01:59:59 am EST.
Then, I run the same commands for a moment just one second later. I will just use the format given in the first example above where I specify the time as UTC and then convert it to America/New_York time:
moment('2017-03-12T07:00:00Z').tz('America/New_York').format('YYYY/MM/DD hh:mm:ss a z')
And my result is correct as expected: 2017/03/12 03:00:00 am EDT - due to daylight savings the time skipped ahead by one hour.
I can then use moment-timezone to go back the other way by passing in an America/New_York timestamp and converting it to UTC.
moment.tz('2017-03-12T01:59:59', 'America/New_York').utc().format('YYYY/MM/DD hh:mm:ss a z')
This gives me 2017/03/12 06:59:59 am UTC
And the next moment in the America/New_York time zone, because of daylight savings coming into play, is 03:00:00 so I convert that to UTC...
moment.tz('2017-03-12T03:00:00', 'America/New_York').utc().format('YYYY/MM/DD hh:mm:ss a z')
... and get 2017/03/12 07:00:00 am UTC which looks correct.
An hour was skipped ("lost") in America/New_York time, but moment can detect that and convert it to UTC.
In Summary, for the spring daylight savings change in the US, I can pass a UTC timestamp into either moment.js or moment-timezone and get back a timestamp in another time zone with the correct daylight savings offset also applied. I can also then pass an America/New_York timestamp into moment and get back a correctly converted UTC timestamp.
My Question
Great, so I want to do the same thing when daylight savings ends in the fall and of course it isn't that simple. My hypothesis is that due to daylight savings effectively causing an hour to "repeat", there is no way for moment to know the correct time UTC. In other words, where there was a gap of one hour when daylight savings started, now we have overlap of one hour.
Question (part 1): Is there a way to pass a relative timestamp and time zone into moment and get back the correct UTC time? When I tried this in the examples below, moment skips an hour on the UTC side.
moment.tz('2017-11-05T01:00:00', 'America/Denver').tz('UTC').format('YYYY/MM/DD hh:mm:ss a z') => "2017/11/05 07:00:00 am UTC"
moment.tz('2017-11-05T01:59:59', 'America/Denver').tz('UTC').format('YYYY/MM/DD hh:mm:ss a z') => "2017/11/05 07:59:59 am UTC"
moment.tz('2017-11-05T02:00:00', 'America/Denver').tz('UTC').format('YYYY/MM/DD hh:mm:ss a z') => "2017/11/05 09:00:00 am UTC"
moment.tz('2017-11-05T02:59:59', 'America/Denver').tz('UTC').format('YYYY/MM/DD hh:mm:ss a z') => "2017/11/05 09:59:59 am UTC"
I assume its because time is happening chronologically like in the example below. UTC offset context is not given therefore I assume that moment cant distinguish between the America/New_York timestamps preceded by asterisks:
*2017/11/05 01:00:00 am America/New_York => 2017/11/05 07:00:00 am UTC
*2017/11/05 01:59:59 am America/New_York => 2017/11/05 07:59:59 am UTC
*2017/11/05 01:00:00 am America/New_York => ???
*2017/11/05 01:59:59 am America/New_York => ???
2017/11/05 02:00:00 am America/New_York => 2017/11/05 09:00:00 am UTC
2017/11/05 02:59:59 am America/New_York => 2017/11/05 09:59:59 am UTC
Again, what I want to know is if there is a way around this? Currently the timestamps in the data that I have does not contain UTC offsets.
Question (part 2): If I am presenting data in the America/New_York time zone then is it correct to think that I will essentially have two hours of data points all stuffed into a (seemingly) single one hour period from 01:00:00 to 01:59:59 on November 5, 2017?
Related Topics
There are a few other topics on SO that are related to this but none that I have found pose or answer this same question. I will link a few here for reference:
Moment.js Convert Local time to UTC time does work
Initialize a Moment with the timezone offset that I created it with
It looks like you have thought the problem through and done some basic research. Thanks!
What you are describing is covered in the moment-timezone docs here. If the data isn't available as a UTC offset in your input, there's no way to tell the difference between the first or second occurrence of an ambiguous local time. Moment picks the first occurrence, because time moves in a forward direction, so this is usually the most sensible choice for most scenarios.
The problem is one of ambiguity. Even as just a human being, if I say "1:00 am on November 5th 2017 in New York" you don't know which of two points in time I'm describing.
That said, sometimes you have external knowledge that can help. For example, if you have an ordered set of timestamps containing time that skips backwards, then you know you encountered a fall-back transition. Say I'm recording data at 15 minute intervals in local time:
00:45
01:00
01:15
01:30
01:45
01:00 <--- this one comes next sequentially, but appears backwards, so infer transition
01:15
01:30
01:45
02:00
You'll have to write your own detection logic to compare one value to the next for that scenario. Also note that if you don't have any time that appears to be out of sequence, then you cannot be assured of which occurrence is being described. A "heartbeat" signal can assist with this in some scenarios.
Now how do you choose the second occurrence in Moment without knowing the offsets in advance? Like this:
First, grab the hasAmbiguousWallTime function from here.
Then define another function:
function adjustToLaterWhenAmbiguous(m) {
if (hasAmbiguousWallTime(m)) {
m.utcOffset(moment(m).add(1, 'hour').utcOffset(), true);
}
}
Now you can do this:
// start with the first occurrence
var m = moment.tz("2017-11-05T01:00:00", "America/New_York");
m.format(); // "2017-11-05T01:00:00-04:00"
// now shift it to the second occurrence
if (... your logic, such as wall time going backwards in sequence, etc. ...) {
adjustToLaterWhenAmbiguous(m);
m.format(); // "2017-11-05T01:00:00-05:00"
}
These two functions should probably be hardened and added to moment-timezone, but they should be sufficient for the scenario you describe.
A couple of other minor points:
Instead of moment.tz(s, 'UTC'), consider using moment.utc(s)
Instead of moment.tz(s, 'America/New_York').tz('UTC'), consider
using moment.tz(s, 'America/New_York').utc()
You may want to review the DST tag wiki for visualization of the problem space.
On part two of your question, yes - you'll end up stuffing two hours of data into what could possibly be visualized as a one-hour space. People have this problem with graphs and charts all the time. They graph something with a constant value over local time, then see a zeroing effect in the spring, and a doubling effect in the fall. Even if you tell moment to use the later occurrence, you won't avoid this unless you actually display the graph in UTC instead of local time.
> os:system_time(seconds).
1470361698
This is correct UTC timestamp, but I'm not sure if it is not system-related value. Is it?
How then I can ensure that same program ran on different machine will still operate in UTC timezone?
os:system_time returns the "OS System Time" which is defined to be approximately the "POSIX Time", the number of seconds since Epoch, which is defined to be 00:00:00 UTC, 1970-01-01, so it should always return the "UTC Timestamp". Erlang has excellent documentation about Time Correction, have a look at the OS System Time and POSIX Time sections.
OS System Time
The operating systems view of POSIX time. To retrieve it, call os:system_time(). This may or may not be an accurate view of POSIX time. This time may typically be adjusted both backwards and forwards without limitation. That is, time warps may be observed.
POSIX Time
Time since Epoch. Epoch is defined to be 00:00:00 UTC, 1970-01-01. A day in POSIX time is defined to be exactly 86400 seconds long. Strangely enough Epoch is defined to be a time in UTC, and UTC has another definition of how long a day is. Quoting the Open Group "POSIX time is therefore not necessarily UTC, despite its appearance". The effect of this is that when an UTC leap second is inserted, POSIX time either stops for a second, or repeats the last second. If an UTC leap second would be deleted (which has not happened yet), POSIX time would make a one second leap forward.
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.
I'm building an application which will be able to send emails at any specific local time to any place in the world.
For example, my daily schedule (localtime):
8:00 AM - Send email to John in Toronto, Canada
9:15 AM Western Standard Time (Australia) - Send email to Bob in Perth, Australia
10:12 PM - Send email to Anas in Rabat, Morocco
I want to be able to execute this code on and Amazon EC2 server in a single location (e.g. São Paulo, Brasil).
I also know that Toronto is in Eastern Standard Time, (UTC - 5h) , but from March 11, 2012 to November 4, 2012, it is in Eastern Daylight Time (UTC - 4h).
I also know that Perth is in Western Standard Time (UTC + 8h), with no daylight savings.
I also know that Rabat is in Western European Time (UTC), but from April 29,2012 to July 20,2012, and August 19,2012 to Sept 30, 2012 it is in in West European Summer Time (UTC + 1h)
To keep track of these combinations of time zone, daylight savings, et cetera, I will, of course insist that all internal server times be in UTC. However, I need some way to keep track of when and how each time-zone jurisdiction switches time zones because of Daylight Savings or (in the case of Rabat) Ramadan, and then adjust my crontabs to accommodate these changes.
Is there an authoritative web service or set of tables somewhere which would help me keep these timezone changes in sync with my desire to deliver emails at the same local time every day to users in different time zones with different switchover dates for daylight savings?
Most programming languages give you access to timezone conversion functions. The most rudimentary ones only work between UTC and the "local" timezone of the server, so you will need a full-featured one, such as pytz for Python that will let you specify a local time with a timezone name (e.g. "America/Toronto") and convert it to UTC for you. Given that, you don't need to worry about the UTC offsets of different timezones (including historical offsets if they've changed) nor DST start end end times: the library will take care of it for you. Just make sure you have the latest database, which comes in the tzdata package.
As for your crontab, you're probably best off if the local timezone on the server that runs cron is UTC, that way you can put UTC times directly in the crontab. On the other hand, depending on the volume of events that you have, I would advice just having cron run your code at regular schedules intervals (such as every 5 minutes) and then your code figures out what events need to be triggered based on the current UTC time and the contents of your database. Then it doesn't matter what the timezone of the server is.
Is there an authoritative web service or set of tables somewhere ...
No, there is nothing "authoritative", but there is something close. It's called the TZ database, and it is currently under the oversight of IANA. Its home page is here.
It is also known as tzdata, zoneinfo, timezonedb, tzdb, the Olson Database, or the IANA Time Zone Database.
There are implementations for just about every language and platform you can imagine. You can read more in the tz-link file from the tzdb, and in the timezone tag wiki, here on StackOverflow.
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.