We have a dataset in Firebase updated by multiple clients.
We want to track the last modified on datetime of the dataset. We cannot rely on the client setting the modified on datetime as their local clock can be totally out of sync.
Is there a way I could have Firebase tag timestamp to a dataset based on its clock to track last modified on?
We're working on some features to support this at the moment, but we don't have a way to do this right now. Note, however, that the IDs created by "push()" are chronologically-ordered, and we compensate for client-side clock skew as best we can when we create them, so if all you're trying to do is make sure some writes to a list occur in order, you can do that with push().
I'd be interested in hearing how you'd like this feature to look. If you have a sec I'd appreciate an email to andrew at firebase...
Update: Firebase now supports setting server timestamps as well as accessing the server time directly on the client. See the documentation here:
https://www.firebase.com/docs/managing-presence.html
We're on the same boat... and I guess sooner or later, many firebase clients will have this issue, as it's a "new kind" of problem we never had to face in the old "client-server" days.
Out current solution (still in the making) is to estimate the time difference between the client and OUR server on initialization, and them compensate,
So - where we had x = new Date(),
it is now x = ourDateService.now()
our now() function simply does new Date() + diff
This works for us,as we don't need millisecond accuracy, and it's a single-page-app that loads once, so we can do this diff-check and initialize ourDateService on load, but this solution will not work for everybody (ofcourse, you can store it in the localstorage/cookie and revalidate every day or so).
Related
Working on flutter/dart project. Calling cloud function from client side and passing 2 dates which are converted toISO8601String.
Printing dates to console while executing cloud-function to double check. They are always valid. After creating document in firestore, the dates are shifted by 1 hour.
I guess because of my current timezone offset which is UTC+1. In summer I had same issue where firestore was shifting my dates by 2 hours because of summer time, resulting in offset UTC+2.
My cloud-functions are deployed at region: europe-west3, which according to firebase docs is Frankfurt. Same time zone as mine (Central European Standard Time). But when I create:
const now = new Date();
Result is one hour less than my local time. Why is that when we are in the same time zone with same offset?
Reading documents from firestore on client side results in inaccurate dates, which is pretty bad for me since I need it to be accurate.
I was searching everywhere but didn't find anything that really helped me. I was trying to construct the date object with many ways but the result was always the same, can somebody please explain me why and help me out? Thanks.
The Java Object Date does not actually contain timezone information, it's just a number of milliseconds since the "epoch" (01.01.1970 00:00:00 UTC) and thus an absolute point in time. It's converted into a valid time every time it's output to a user.
So it seems that the reason for the time shift is that your PC or the browser you are viewing your firestore documents from is set to the wrong timezone.
For further information, take a look at this question or the java documentation.
Can someone give little clarification how to interpret following parameter:
deletionRequestTime: datetime`:
This marks the point in time up to which all user data for the specified end user and Google Analytics property or Firebase project should be deleted.`
If I set it to 1st Jan2018 (GTM), does it delete all user data:
from that date till today (which is how I interpret).. meaning all 2018 data will be gone?
or, (from epoch time) till that date ... meaning all 2016/2017 etc. data is gone and all that remains is 2018 data?
When trying the API > refreshed User Explorer report in GA interface > I notice all-time data seems is gone (giving me impression that this filed is not respected?). But let me wait 72hrs since API request to draw any conclusion..
Thanks for any clarification.
Cheers!
First off i dont think your miss-interperting it I dont think the documentation is clear.
The following is from userDeletionRequest
deletionRequestTime datetime
This marks the point in time up to which all user data for the specified end user and Google Analytics property or Firebase project should be deleted.
Now to me that means that its a point in time that the data should be deleted. as in one day? one minute a time stamp? would this then mean you will need to loop though every hour minute in a day to delete everything.
My current answer is this is confusing. I am going to contact the team for clarification they are in West coast USA we wont get an answer back for several hours. I will updated this when i know more.
Clarification from Google
As per documentation, deletionRequestTime represents a timestamp up to
which all use data will be deleted. In other words, all data from the
beginning of time until the point returned in deletionRequestTime will
be deleted.
I don't believe you can set the deletionRequestTime field. It is set to the time you make the call.
I believe that is why you are seeing this behavior.
I am stuck in a case where Google Analytics is recording multiple eCommerce transaction. We have added code on server side to execute GA eCommerce posting code only one time. Still this issue is reproducible for some transaction. The multiple eCommerce transaction are for same transaction Id but on different dates.
On research I found that this case is with small devices (mobile, tablet). The small devices browser caches whole webpage. And when the browser is opened it reload webpage from cache. So each time user opens the browser and page loads from cache hence the causing this issue.
Can anyone help me on this?
Thanks
"Ignore double transaction ids" would be quite a useful setting and we should try and make this a feature request. However at the moment it does not exist.
The only way I can think of would be to use an API script that selects the transaction ids for the last "n" days and then inserts a heap of filters via the management API to exclude hits with that transaction id. After some time (when the caches have presumably expired) you could throw out old filters. This would be only feasible if you have a small number of transactions (I think there is an upper limit to the number of filters a view can have).
Or if your transaction ids are somehow sequential (e.g. if they contain the date) you might be able to construct a regex that matches earlier parts of the sequence (e.g. previous dates) and only let's a transaction pass if it is higher up in the sequence than the last recorded transaction id (or does not let it pass if the date in the transaction id is lower than the current date - remember to update your filter at midnight).
Caveat: I have not actually tried something like this, but it sounds like it should work.
Recently started exploring the Firebase data via the Data Studio Firebase connector. I'm doing some custom reports based on the user_engagement event to compare with data we previously reported on in Flurry.
When looking at some DAU figures they are pretty close but on MAU they tend to get inflated. (Saw this behavior first on the Firebase Events Report Template). Digging into it a little more we do have a pattern where users frequently reinstall the app which generates a new app_instance_id. So as I fallback I'm using the resettable_device_id but then there's the situation advertising tracking is disabled on device resulting in a zeroed value. (Or for a brief period in January nulled out values, not sure if this was client or part of the Firebase link)
Currently thinking something roughly following the logic below, falling back to app_instance_id if the advertising identifier was not set. What approaches would be worth looking into to have a reliable user identifier for metrics reporting? (In future will be calling the setUserID to utilize our own identifier but looking to match up historical data)
IF(user_dim.device_info.resettable_device_id is not null,
IF(user_dim.device_info.resettable_device_id = '00000000-0000-0000-0000-000000000000', user_dim.app_info.app_instance_id, user_dim.device_info.resettable_device_id),
user_dim.app_info.app_instance_id
) as unique_user_identifier,
Thanks in advance.
Simpler way to deal with the cases where a resettable_device_id is not available:
IF(user_dim.device_info.limited_ad_tracking, user_dim.app_info.app_instance_id, user_dim.device_info.resettable_device_id) as unique_user_identifier
I would like to be able to display time based on the user's current time zone. I will be storing times in UTC format in my database, but wish to normalize these to the client's time zone. So far the option that seems most viable is to capture the clients time and then deteremine the difference between that and current UTC and use that delta to normalize times when rendering. I would like to know if there are any more straight forward options available to detect and normalize a UTC time to that of the requesting client's machine.
I would use the javascript dateObject.getTimezoneOffset(). Even if their time isn't set accurately, hopefully they've set their timezone:
http://www.w3schools.com/jsref/jsref_getTimezoneOffset.asp
You can use this value to calculate an offset between the server's time and the client's time. (as Jason helpfully pointed out in a comment below)
In addition to, or instead of using getTimezoneOffset, you should consider permitting the user to specify preferred timezone in their profile. For instance, a user may be visiting in one timezone, yet may prefer to see time displayed in his home timezone.
Also, if this were as simple as calling a JavaScript function, then sites would never have to ask for your timezone.
A much better approach is to store per-user the exact time zone the user is in (and optionally) allow them to select if they observe daylight savings time (if it's applicable to their time zone.) You can of course, automatically fill in the DST information (based on the time zone) if you wanted.
You'd have to make this part of the sign-up or possibly in their "options".