I am currently trying to create my own Google Agent using DialogFlow and while everything is going fine, I am finding myself unable to solve the smallest of problems.
Google has a tendency to add an additional year to the datetime object whenever I state a date. An example:
If I say "How much did we produce 29/6?" (6/29 doesn't work either) it will grab the date and format it correctly to the 6th of June, however it will make it year 2021 instead of 2020... Is there any way to make it default to our current year, unless I specifically say a different year?
Can you try saying "How much did we produce on June 29th?" I think it may have some issue processing the string "29/6" and somehow it gets translated to 6th of June.
You had mentioned "6th of June" is formatted correctly when giving "29/6", shouldn't it be "29th of June"?
Related
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.
As the title suggest, I would like to get the previous month using the given month from Get System Info. I used Get System Info step to get todays month and year, and from there I would like to get the previous month. This is so it would be dynamic and I can ran this any day and still get the correct filter rather than making a hard coded year and month. Is this possible? If so, how do I do that?
Here is how I did it. This is the overview
Here is the calculator:
And concatenate fields:
There is still a few loop hole on getting the previous month during January. But, that is how I did it.
When getting information from Twitter's API for a user, they provide two fields related to the user's time zone:
utc_offset: -14400,
time_zone: "Indiana (East)"
Unfortunately, this doesn't tell the full story because I don't know if that UTC offset was calculated during standard time or daylight savings time. After dividing by 3600 seconds, I get -4 hours, which is valid during the summer months, but in the winter the correct value would be -5 hours.
If the value was ALWAYS determined by the daylight savings time value then I could write an algorithm for that, however after some searching on the subject I've seen several pasted outputs that contradict that assumption. (as a quick example, this question shows his/her offset as -21600 and then he/she says he/she is on central time, which if calculated during daylight savings time would be -18000).
It would make sense to me that the value would be calculated as of Jan 1 and the several pasted outputs I've found online fall into that category, but my own Twitter account shows the values listed above for which this assumption is invalid. My next thought was maybe it was calculated at the time I created my account, but then that seems erroneous as well because I can change my time zone at any later point (and even so, I created my account in November when I would have been on standard and not daylight time!).
My last thought was that maybe the value is being calculated by the date of the API request. This makes a lot of sense and the Twitter accounts I own all seem to validate this. BUT, the SA question I linked to earlier shows that the person answered the question on June 2nd, which is daylight savings time and his/her value of -21600 reflects a standard time for the Central time zone.
Anyone out there solve this problem? Thanks so much!
Twitter's front end uses Ruby on Rails. If you go to your own twitter account settings and look at the possible options for time zones (view source on the dropdown list), you will find that they match up with those provided by ActiveSupport::TimeZone, shown in this documentation. Although there appears to be some zones understood by Rails that Twitter has omitted, all of the Twitter zone key names are in that list.
I have asked Twitter to use standard time zone names in the future, in this developer request.
Why does Rails limit this list and use their own key values? Who knows. I have asked before, and gotten very little response. Read here.
But you can certainly use their mapping dictionary to turn the time_zone value into a standard IANA time zone identifier. For example:
"Indiana (East)" => "America/Indiana/Indianapolis"
"Central Time (US & Canada)" => "America/Chicago"
This can be found in the Rails documentation, and in the source code. (Scroll down to MAPPING.)
Then you can use any standard IANA/Olson/TZDB implementation you wish. They exist for just about every language and platform. For further details, see the timezone tag wiki. If you need help with a specific implementation, you'll need to expand your question to tell us what language you are using and what you have tried so far. (Or consider asking a new question about just that part of it.)
In regards to the utc_offset field, twitter does not make it clear what basis they use to calculate it. My guess is that it is the user's current offset, based on the time that you call the API.
Update 1
I have added support for converting Rails time zone names to both IANA and Windows standard time zone identifiers in my TimeZoneConverter library for .NET. If you are using .NET, you can use this library to simplify your conversions and stay on top of updates more easily.
Update 2
Twitter's API now returns the time zone in this format:
"time_zone": {
"name": "Pacific Time (US & Canada)",
"tzinfo_name": "America/Los_Angeles",
"utc_offset": -28800
},
Use the tzinfo_name field. Done. :)
I'm using fullcalendar 1.6.4 in conjunction with a Drupal 7 site; all is well except that I'm getting the wrong number of weeks for some months with weekMode set to "variable" or "liquid". For September 2013, I get four rows of weeks, which means that I lose the last two days of the month. Most other months appear correctly, although December 2012 is shown with 5 weeks (losing the 30th and 31st), and January, February, and October 2013 are all shown with 6 weeks (one more than is needed).
I've been doing some quick hacking around with the render() code where the starting and ending dates seem to be worked out, but haven't come up with anything clearly better. So: are other people seeing this / is it a known issue / have I screwed up something with my installation? Thanks!
I think there's a bug here: in fullcalendar.js's MonthView.render(), it looks like the AddDays computation of visEnd (l. 1984) is getting messed up by firstDay getting string-concatenated into the value instead of added. visStart may be getting similarly affected, since it does pretty much the same thing. In any case, I stuck the line firstDay = parseInt(firstDay, 0) after the var FirstDay... statement, and things are working properly for me. This may not be the preferred way of handling the matter, but I think something like this is going on. Opinions from other eyes?
This is not a Full Calendar bug, but instead a bug in the Drupal implementation of Full Calendar. Drupal allows users to override the "start of the week" option (values of 0 to 6). Drupal is incorrectly storing this value as a string instead of a number.
See Drupal issue I opened.
I have a database that tracks employee’s data for the current year and previous years.
In examples below I will use calendar years (years start in Jan and end in Dec)- this is not always the case, some users have their year running from July to June- or April to March, etc.
There are many tables that, with a few heavy calculations, make a view of the employee’s data at this point in time.
This current year’s data is what users look at mostly. But data from previous years impact on this year (so, a change made to the 2008 data- will have a knock on effect on 2009, and then into 2010 and so onto this year).
Obviously, this has a negative impact on performance when viewing reports as viewing this year’s data will mean trudging through all the previous years- calculating and creating views until the end result is found. As the application ages, this problem will get worse and worse- say in 2015, anybody using the system from its inception (2008) will be waiting for a long time to get their data.
We plan to freeze previous years data so instead of having data from 2008, 2009, 2010 and this year’s data- we would have one block with the previous year’s data (with all calculations done for those previous years) and this year’s data.
In this way, we would have the end results data for all the previous year’s already calculated and we would only need to add to this year to get the final result.
Obviously, we would have to prevent users from entering/updating data in previous years.
My question is what is the best way to achieve this? I presume you would need some process that waits until the new year and does some calculations.
Thanks in advance,
ViperMAN.
the approach you describe is normally referred as data archiving, you can have some queries a DBA runs manually every year the first working day after the new year party so the calculated data is prepared and stored.
Also, your application needs to deny users to modify previous years data, if I have got it right.
One approach I was thinking works as follows:
Create a table that holds the result of the previous years calculations.
Prevent all addtions/deletions/updates to previous years from the app tier.
Change reporting so that queries would consult this table instead of trudging along, calculating everything out each time.
Have a daily process that would:
Check if today was the first day of an employees year-
If yes, get all of the elapsed year's data and add them to all the previous years.
Obviously, this is a simlified version- but one that I think could work.
Thoughts?
If you have data that should not be edited, and you can define what that data is, then I would use a combination of stored procedures and security settings to ensure the old data stays accurate.
If you used stored procedures as a filter, you can have logic in your stored procedure that checks the record against the current DateTime and only allows the update if everything fits your requirements.