I noticed today that an updated iOS version of the Google Tasks app includes the option to set the time in addition to the due date. A welcome improvement, and the due datetime from the iOS app properly appears on the Gsuite website. But, I don't see the time when getting the Task from the API.
Should the API be returning the proper time? All I get is 00:00:00 the same as always.
If it matters, I'm using the PHP API client. Just updated today with composer to be sure I had the most current version.
At the time of writing, according to Google's documentation for the Tasks API:
The due date only records date information; the time portion of the timestamp is discarded when setting the due date. It isn't possible to read or write the time that a task is due via the API.
https://developers.google.com/tasks/reference/rest/v1/tasks#resource:-task
Related
Can Firebase get accurate time for offline records which have been stored in device when the device's clock has been changed? The device's clock might be changed when the user rebooted the device or when the user adjusts the date time manually.
My case is quite similar to Get actual DateTime of a device in Offline Mode which I can quote here 1) The application can work in online as well as offline. The app has a feature to create and save the NOTES inside the application. Also, When the app gets internet connection, I need to send the NOTES to backend server. I have a field called 'DATECREATED' in each NOTE (the datetime where the actual NOTE was created) ISSUE: If the User has set the DateTime wrongly in the device, My application sends the incorrect DATETIME to server.
I am going to handle the offline issue on Android and IOS platform, so I came out with another possible solution such as get the GPS time, using some sort of background counter, etc. Based on my experiment, the solution are not reliable enough and some might difficult to do. That's why I decided to get the accurate timestamp using Firebase.
I read a reference https://firebase.google.com/docs/database/flutter/offline-capabilities#clock_skew, but I am not quite sure whether it can help me to get accurate time for offline records.
There is no way you can get a server timestamp while offline. Why? Simply because the timestamp is totally generated on the server. And since you're offline and cannot communicate with the server, you cannot get an estimation. So there is no other system that can generate a timestamp other than the Firebase server.
Besides that, a date that can be generated on the client can be manipulated, so you cannot rely on that.
The option that you have in my opinion would be to have two fields. One is for the real timestamp, which you'll be received when you're back online and the other one is what the client provides. In that way, you make a comparison, if this is what you want.
Edit:
Firestore, is a Cloud hosted NoSQL database. So there is no way you can generate an accurate time while the user is offline. What you can certainly do is calculate the period of time while the user is offline. This means that you have to calculate the number of minutes the user has lost connectivity. Let's say a user losses connectivity for 10 minutes, when it regains connectivity, you receive the Firestore timestamp. Now, all you have to do is to subtract those 10 minutes from the received timestamp in order to have the accurate time that you're looking for.
Two days ago, we started presenting some issues with our cadence setup.
The first thing we noticed is the Open workflows were not disappearing from the list once they completed. For example this workflow appears as Open in the list:
But when you click on it, you will see that it’s actually completed:
At the same time this started to happen, we noticed how several workflows would take quite a long time to complete, several of them would stuck in “Schedule” states and never go further from there. After checking the logs, the only error we saw was this:
{"level":"error","ts":"2021-03-06T19:12:04.865Z","msg":"Persistent store operation failure","service":"cadence-matching","component":"matching-engine","wf-task-list-name":"cadence-sys-history-scanner-tasklist-0","wf-task-list-type":1,"store-operation":"create-task","error":"InternalServiceError{Message: CreateTasks operation failed. Error : Request on table cadence.tasks with ttl of 630720000 seconds exceeds maximum supported expiration date of 2038-01-19T03:14:06+00:00. In order to avoid this use a lower TTL, change the expiration date overflow policy or upgrade to a version where this limitation is fixed. See CASSANDRA-14092 for more details.}","wf-task-list-name":"cadence-sys-history-scanner-tasklist-0","wf-task-list-type":1,"number":6300094,"next-number":6300094,"logging-call-at":"taskWriter.go:176","stacktrace":"github.com/uber/cadence/common/log/loggerimpl.(*loggerImpl).Error\n\t/cadence/common/log/loggerimpl/logger.go:134\ngithub.com/uber/cadence/service/matching.(*taskWriter).taskWriterLoop\n\t/cadence/service/matching/taskWriter.go:176"}
Does somebody have an idea of why this is happening?
The first one is because of visibility sampling being enabled by default(to protect default core DB). You can disable it by configure system.enableVisibilitySampling to false.
But when you doing that, it’s better to separate the visibility and default store into different database cluster so that visibility doesn’t bring down the default(core data model) DB.
see more in https://github.com/uber/cadence/issues/3884
The second is a bug fixed in 0.16.0
It should be resolved if you upgrade server.
See https://github.com/uber/cadence/pull/3627
and https://docs.datastax.com/en/dse-trblshoot/doc/troubleshooting/recoveringTtlYear2038Problem.html
In my Delphi Windows application i need to login every day.
at first i used system date (11-11-2019) and i compare system date to stored one every time on OnCreate if date is different i call login.
But the system time can be paused right ? Then i thought of server time but checking server time on every OnCreate is not efficient i think as my app launches many times.
Can't use token based system to check as i am using firebase REST-API backed and it's token is expired in every one hour however if i use token based i still need to compare it and the system time might be paused.
How to effectively check if date is changed ?
The inapp time is short as the work is done in 10 seconds and the form may be then closed by user and the next app start time may be less a minute so why call for the server time again ?
You can check the current date and time querying a NTP server.
See this answer for more details.
I'm using the Core Reporting API (Reporting API V4).
Is there any way for me to determine the last time the data my query is returning was updated?
I'd like to be able to indicate whether the data being displayed was last updated several hours ago versus several minutes ago.
The API does respond with isDataGolden which tells you if the data will change again, if your website is small the data processing latency could be almost nothing.
From your question it sounds like you are more interested in not just if the data is stale but how stale. You could request the the ga:hour and ga:minute to find out when the last processed hit was recorded.
Note there is also the Realtime API which gives you a read of what is happening instantaneously.
I need to set the date that JVM would normally get from the OS.
Why? We have an app that interacts with a legacy app. All data on the legacy is always some date in the past (the client does reporting on a saved copy of live data (yesterday's data ) so as not to affect the response time of transactions on the live machine and demo's are done on dev machines, also some date in the past)
Our app needs to post transactions no later than the date on the legacy app. The legacy app lives on a different server. We have a process that returns the current date of the data and need to get the Java app to work entirely on that date.
We can't change the system date since a datawarehouse also runs on that box. So the only alternative is to change the date that JVM thinks it's getting from the OS.
Any ideas?
Own java agent should do the trick:
http://blogs.captechconsulting.com/blog/david-tiller/not-so-secret-java-agents-part-1
I suppose that intercepting System.currentTimeMillis() calls should be enough.