Our Gmail Email Markup was working fine for more than a year. Now it shows the incorrect time in the bubble above an email. It still adds the event to the calendar with the correct time.
The event time: June 22, 2020, 17:00 (15:00 UTC). Computer local time is UTC+2.
The Email Markup
The Email Bubble as Rendered in Gmail (Notice the time is shown as the UTC time, not local time.)
The Calendar Event Added (Note this time is correct).
I think it is pretty clear there has been a bug introduced that causes the dates to no longer display correctly in emails. However, no one else seems to be saying anything about this, so it makes me wonder if somehow I am implementing this incorrectly. Does anyone have insight into this problem?
Writing this question got me thinking. I realized that email bubble within Gmail just displays whatever the startDate time is without converting it to the local time of the user. So while I was using:
"startDate": "2020-06-22T15:00:00Z"
what I wanted was the same time, but in local time.
"startDate": "2020-06-22T10:00:00-05:00"
Both of these add the event to the correct time in the user's calendar. However, they will display differently within Gmail itself. It's possible that this adjustment by Google is actually a bug-fix that also broke my code.
Related
I applied for the Email Markup and on Feb 10, 2020 I received an email from Google Markup team telling that my domain was whitelisted.
They also specified that it can take up to a week after whitelisting to take effect.
It's 17 days already and I test my emails dailty, thought neither go-to action button nor Event reservation appears in my email.
Does anybody know if it can take longer then 1 week after whitelisting?
I texted them back but still no response.
It takes at least 3 weeks to start showing on the emails.
I am working on rails 4 application. I want to show the time for comment I created. If I open the site in india then time should be shown in IST (according to indian standard) and If I am in USA so for the same comment that i made in india time should be shown according to USA time zone.
What do I need to do in my config file for development and production?
Do I need to change anything in database?
Please help me.
Rails always saves times in UTC (universal time), and the server has a setting which tells it which timezone it (the server) is running in.
To show different times to the client, Rails (which runs on the server) will need to know which time zone the client is in. This isn't in a standard request header so you will need to get them to submit the information somehow. Once you know their timezone you can ensure that you always show times to the user using their timezone - there are helpers for this.
Getting their timezone can be done explicitly, eg by giving them a timezone dropdown in their "My Account" page, and then saving that in their user record, and/or by making it more upfront and forcing them to choose one in a popup, if you don't know it.
Or, you can do it for them using Javascript, passing it through in a cookie. See this article for an example of how to do it.
http://thisbythem.com/blog/clientside-timezone-detection/
Well one solution can be to store the time zone of the user in the database, write a filter
around_action in your ApplicationController which would set the Time.zone to the time_zone from the database field.
You might want to look at Time.zone and TimeZone in the rails api
Here is a railscast , you can figure it out from the comments and the github link.
Since today (July 5th 2012) Facebook changed the return value for events from a unix timestamp to a string. This messed up my iOS app that displays concert dates.
I grab the event data from the event fql table.
When i look at the json i get back from Facebook, i now see a string like this:
"2012-10-07T19:30:00+0200".
Now, if the event creator did not post a start time for the event on facebook, the api just returns "2012-10-06" - with no time attached, and it returns the event one day to early.
While the facebook page in the browser displays the event date correctly, the api returns the date one day too early.
What is going on here, am i missing something and what is the right way to handle this?
From yesterday everything went back to unix format, i checked and found out that this kind of string ("2012-10-07T19:30:00+0200") was a bug! only some apps were receiving that and in fact the graph api explorer never used it and always used unix time...Thank you facebook, now i have to change everything for the second time in one week.
Here's the bug link:
https://developers.facebook.com/bugs/415058451869226?browse=search_5001222c9ff516a78134883
Is there a way to create a SharePoint 2007 calendar that only allows users to input appointments in certain time slots? I would like the time slots to run Monday thru Friday from 8am - 10am, 10am - 12pm, 1pm - 3pm, 3pm - 5pm, and 5pm - 7pm. Only one person can sign up in a time slot at a time.
I do not want to have to enter every date from now till the end of time, which is the how this solution works: http://sharepointsolutions.blogspot.com/2009/02/give-blood-to-your-workflow.html
That is a great solution for the one-time Blood Drive type of time slotting but not exactly what I need.
I would either :
adapt the new form or create a custom one that will prevent people from adding a new event outside of your specified time slots and ensure that a specific time slot is not registered by someone else prior to save it. That will allow you to create a dedicated UI with relevant controls (eg : dropdown lists that have only the hours that you specified)
add an event handler on ItemUpdating that will ensure that there is no collision with another event and validate your business requirement regarding time slot. You can then transfer to an error page with a proper explanation message
Both solutions require custom development. I would be glad to hear if there is something out of the box that would fulfill this need.
I'm working on a Rails application that's kind of like a blog. Users create Entries. I'm trying to work out how to handle time storage and display. I've read this writeup about Rails timezone support.
It's great but it doesn't cover what my app needs to do. It only looks at cases where you want to convert stored time to the current logged in user's time zone. In contrast, the effect I want is...
A user creates an entry in California at 10:00 a.m.
A couple years later he moves to New York and then at some point looks at his old entry. The "created" date should say "10:00 a.m." He doesn't care about time zones. He just wants to know what time of day he felt like it was when he wrote the entry.
If he then edits the Entry in New York the displayed "modified" date is, again, his subjective time of day when he made the edit. (Let's assume he went to "preferences" and changed his time zone setting when he moved.)
Also, for the sake of thoroughness, the app should be able to report the "real" absolute time when an Entry was created or updated.
(Note -- my imaginary user is a guy, but for women it should work roughly the same way.)
The way I'm thinking of implementing it is...
Have the attributes User#time_zone, Entry#created_at_utc, and Entry#updated_at_utc in addition to the standard created_at and updated_at.
The user selects their time zone from a menu when they sign up. (They can change it later if they want.)
The app uses User#time_zone to store created_at and updated_at in the user's subjective local time. If it's 10:00 a.m. for them, the app writes "10:00 a.m." to the DB.
The app also saves the current UTC time in the aforementioned _utc fields to deal with the last requirement above.
Is that a good way to do it? Is there a better way?
The two roads you can take are:
Store a timezone (UTC) in the user account as well as in every post - update the post's timezone along with the updated_at field whenever the user changes the post (if he or she has changed timezones).
Store the timezone only in the user account. When the user changes timezones, update every post that belongs to the user and add/subtract to the created_at/updated_at dates.
The first option seems like the cleanest option to take. For this you would only have to create a new method in your post record:
def locational_updated_at
updated_at + timezone.seconds
end
Where timezone is an integer containing the seconds since UTC.
If you can, you should avoid storing two different sets of timestamps, and you should avoid storing any non-UTC dates. Both of these things will lead to confusion. I'm not completely sure I understand what you're doing (though I like your idea of subjective time), but wouldn't it be enough to just attach a time zone to every post, and always use that zone to display the times? It would default to the time zone set in the author's account, so he could change it when he moved cross-country without affecting previous posts.
I think that's all you need--to attach a time zone to every post. Is that sufficient? Or am I missing some part of this?