I noticed when PingFederate(PF) sends the date it is off by a day from my Rails app. It appears that the PF date is the one off by a day. For example in the PF SAML response I get:
<saml:Assertion ID="pEaf1kce93SpAxfIpuohOv6QP-T" IssueInstant="2014-05-03T03:15:20.020Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
and
<saml:Conditions NotBefore="2014-05-03T03:10:20.021Z" NotOnOrAfter="2014-05-03T03:20:20.021Z">
whereas in Rails I get
Time.now = 2014-05-02 20:15:19 -0700
which makes me think that I need to set the date in PF. Note that PF is running on the same computer that the Rails app is running on.
Is there a way to set the date in PF?
The time is off as well. Is there a way in PF to set the time too?
SAML assertions are always in UTC. Which is what PingFed is using. Set your Rails application to use UTC as well.
I don't see why you think that the time is off. Your time from Rails is 2015 and -7. That means in UTC, it's tomorrow at 0315 - when it was issued. PingFed is setting an allowance of +/-5 minutes, so the SP should not accept it before 0310 or after 0320.
Your server and PingFed are correct so far...
Related
I have a fixed window of 1 minute. I am considering event time.
beam.WindowInto(window.FixedWindows(300))
When I deploy this code ,is the window created instantly even if I have not published any message .suppose I deployed at 6:30 , is it like the windows are automatically created as 6:30 to 6:35, 6:35 to 6:40 and so on ?
If I publish a message to topic having
event timestamp = 6:31 (unix seconds i.e 10,176589653)
when system time = 6:36
..does it mean the watermark for that specific message is at 6:31 and it will miss the window as system time is at 6:36 and allowed lateness=0 and will be rejected.
Windows are always created using UNIX time 0 as a base, meaning, no matter if you start the pipeline at 6:31, 6:32 or 6:35, the windows would always be [6:30, 6:35), [6:35, 6:40).... Note that this also applies for days, the windows would start at 00:00 UTC.
If you want to change this, there's an offset parameter.
I am trying to validate the system time of client’s computer with the actual time (internet time). If for some reason the client’s time settings are not correct or the time and timezone don’t match the local time, I want to notify them to sync the time with their local time in order to use the application. If my question is not clear then this is something that I am trying to mimic, https://knowledge.autodesk.com/support/autocad/troubleshooting/caas/sfdcarticles/sfdcarticles/Incorrect-System-time-warning-when-starting-an-Autodesk-360-application.html
How can I do this time comparison/validation in dart?
The main question is IMHO what accuracy you need.
You can just query a NTC and report if there is a discrepancy. If the server is synchronized with such a time server, there shouldn't be a problem.
You can also add an API to your server that returns the server time.
Then you read the time from the local system and from the server and check the difference
bool compareTime() {
var serverTime = await getTimeFromServer(); // not yet existing method to fetch the date and time from the server
var clientTime = new DateTime.now().toUtc();
var diff = serverTime.difference(clientTime).abs();
if(diff > const Duration(seconds: 5)) {
print('Time difference too big');
} else {
print('Time is fine');
}
}
Ensure that the time returned from the server is UTC as well, otherwise you're comparing apples with pears.
If you're running server-side, you can shell out to ntpdate -d pool.ntp.org and read the output, parsing the last line. If the time offset is small enough, you're good.
For browser apps, see the StackOverflow at Getting the current GMT world time for a few options.
I'm using Ruby on Rails (v3.2.13), Dalli (v2.6.4) and MemCached (v1.4.13).
I do caching like this:
result = Rails.cache.fetch("test_key", :expires_in => 1.week) do
get_data() # slow call, result of which should be cached
end
I want to update cache expiration date based on the data, since some of my data can be kept longer.
Right now the following code does the job:
if keep_longer(result)
Rails.cache.write("test_key", result, :expires_in => 6.months)
end
I know that MemCached supports "touch" command that allows to update expiration date without sending the value. And I don't see how to use it through the Dalli gem. Is there a way to update expiration date without resending the result?
UPDATE:
Rails.cache.dalli.touch('some_key', 24.hours)
This should work, but for me it doesn't. Does it work for you?
Here is small example you can try. After execution of the following code in the IRB
dc = Dalli::Client.new("localhost:11211")
dc.set("test_key", "test_value", 5.minutes)
dc.set( "key", "value", 5.minutes)
dc.touch( "key", 10.minutes)
I'm checking the expiration dates using telnet:
telnet localhost 11211
Then given the correct slab_id and using "stats cachedump" command I obtain expiration times in seconds:
stats cachedump 1 0
ITEM key [9 b; 1375733492 s]
ITEM test_key [14 b; 1375905957 s]
Note that the expiration time of the key "key" points to the past. When I expect it to be 300 seconds later than "test_key" expiration time. Also I noticed that "key" expiration time is approximately 1 second before the MemCached server has started. Which probably indicates that this key has no expiration time. And in fact "key" doesn't get deleted in the near future.
Am I doing something wrong or it is a bug of Dalli/MemCached?
Dalli does support this - there's a touch method on Dalli::Client that does exactly what it says on the tin. Rails.cache returns a cache store rather than the underlying Dalli object so you need to do
Rails.cache.dalli.touch('some_key', 24.hours)
To bump the cache entry's expiry time by 24 hours (and of course memcache may decide to drop the entry anyway)
I found that my version of MemCached (v1.4.13) has the bug: binary touch operation did not update expiration time correctly. This bug was fixed in v1.4.14 (release notes):
Fixed issue with invalid binary protocol touch command expiration time
The problem now: as of today versions v1.4.14 and later cannot be installed using apt-get.
I am having a bit of a weird issue:
the date function gives timezone=MST
the date function from the centOS prompt gives me EST
the phpinfo() function returns America/New_York
As Plesk was showing America/New_York but centOS was not, Techsupport did something to the
/usr/share/zoneinfo/ files, because they said that somehow the New_York file was showing MST (Mountain Time).
After that operation, centOS time and phpinfo() display EST correctly but the date function still display MST.
Any ideas?
Did you tried date_default_timezone_set()?
Since PHP 5.1.0 (when the date/time functions were rewritten), every call to a date/time function will generate a E_NOTICE if the timezone isn't valid, and/or a E_WARNING message if using the system settings or the TZ environment variable.
I've been retrieving json from my web service, with the data containing [0.0] in odd places, such as in the middle of "tit[0.0] le". I'm viewing the info in the console, so I just ignored it as when I actually use it it is not present.
However, I'm currently building a calendar and placing the retrieved events in it. The problem with a particular event is that the [0.0] seems to be lodged in between the timestamp 2012-03-[0.0] 01T00:00:00. It's only happening with this event that the [0.0] is not going away when I use it. Of course, the httpdateparser cant retrieve the date properly, with it interpreting it a day early. I think the [0.0] is the cause.
How do I get rid of the [0.0]? parse it out? I don't think it is actually there...
EDIT:
it looks like the [0.0] are just added by the blackberry console for viewing purposes.
But why is it only on the two events that are not working correctly?
full_date:2012-02-29T00:00:00
full_date:2012-03-01T00:00:00
Both these dates are parsed using the following:
Date date = new Date(HttpDateParser.parse(date_full));
c.setTime(date);
int theMonth = c.get(Calendar.MONTH);
int theYear = c.get(Calendar.YEAR);
int theDate = c.get(Calendar.DAY_OF_MONTH);
For theDate I get feb 28 and 29 respectively. Does this have to do with leap years? I thought Calendar delt with this stuff?
Check the list of valid date formats on the API. I found "yyyy-MM-ddThh:mm:ssTZD" (eg 1997-07-16T19:20:30+01:00) is on it. Maybe you need to append timezone information.
[EDITED]
Adjusting the date comes from web service to the device timezone may fix the problem. When calender.get(property) is invoked it considers device timezone.