I got in to a strange problem.I am creating an ICal file through razor code and when i download ICal from wesbite it shows wrong time in it.
However when I open it with a notepad correct time is printer there.
to describe this in detail I will produce a sample.
Ical open in notepad
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20130107T150000Z
DTEND:20130107T170000Z
DTSTAMP:20130107T131549Z
ORGANIZER;CN=it#rk.com:mailto:it#rk.com
UID:u20vfrto8rfd9cscp52sn9o#google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=;X-NUM-GUESTS=0:mailto:
DESCRIPTION: INGBOARD IS IN ENGLISH.\n\nLand: Denmark\n
LOCATION:
STATUS:
SUMMARY:US Company
END:VEVENT
END:VCALENDAR
In this time is correct start time as 15.00 and end time as 17.00
When I open this in Outlook it shows start time as 8.30 PM and end Time as 10.30 PM which is wrong.
How can I fix it?
The start and end times are explicitly specified in UTC (due to the trailing Z). If Outlook is displaying them in local time, that would explain the difference. It sounds like Outlook is in an Indian time zone (which is UTC+05:30 at the moment).
You may well want to specify a local start/end time, and separately the time zone of the event. (If you don't specify the time zone, it won't start at a specific instant in time, which would be unusual for most events.)
Related
I have a simple system, which on node creation form, allows user to select start and end dates along with hours and minutes:
The problem is that the date gets messed up somewhere in the middle, or I don't know how to convert it.
In the database, two values gets saved as follows:
start: "2019-08-01T14:00:00.000Z"
end: "2019-08-01T16:00:00.000Z"
Seems correct, as in the datepicker I chose 2pm and 4pm. Then, using momentjs and react-big-calendar, I try to put that event into calendar. It seems that it puts +3 hours every time. I assume, it is because it saves it in UTC format, and I live in Eastern Europe, which is +3 hours from UTC.
What is strange, is that I already get back time converted to my own when I make a request to the database:
Thu Aug 01 2019 17:00:00 GMT+0300 (Eastern European Summer Time)
Could someone help me out? I would expect to have the same hours returned and displayed, as I save them, meaning if I select 2pm, it should be 2pm. I think the solution here would be to ignore timezones, and always display everything in UTC? But how to do that? I have access to momentjs if that helps. I tried something like this:
moment.utc(event.start);
But it still returns the same value, which is:
Thu Aug 01 2019 17:00:00 GMT+0300 (Eastern European Summer Time)
When you setup React-Big-Calendar, you define a localizer. By default, the calendar will display in the local timezone of the browser the user is using. Any and all dates given to the calendar will be converted to that local timezone. If your dates, coming from the db, use an offset of +5, but you're sitting in +3, it will automatically convert those times to display +3 (part of the beauty of UTC).
This is where it can get tricky. Say I want to get all values from my db between Sep 19th and Sep 21st. I have to remember those offsets when requesting data from the system. I could use moment and say moment('2019-09-19').startOf('day'), and it would give me 2019-09-19T00:00:00Z, but this isn't exactly correct for me, as I'm at an offset of -5, which means I actually needed 2019-09-18T19:00:00Z to get the start of my day. The same holds true for my end datetime, where I would say moment('2019-09-21').endOf('day') and it would give me 2019-09-21T23:59:59Z, when I would need 2019-09-21T18:59:59Z.
Now, I'm not positive of this (you'll have to do some testing), but if you use moment-timezone instead of moment it may handle all of this for you. You'll have to play around to know for sure.
FINAL EDIT: I worked out timezone handling with moment-timezone as my localizer. I put the entire thing in a GitHub project, as well as creating a CodeSandbox where people can play with it.
TRULY FINAL EDIT: The (0.36.0) latest version of RBC has full timezone support now, when using either the momentLocalizer or the new luxonLocalizer. Doc site isn't up to date yet, but if you run the 'examples' locally you'll find all the info.
When a mail in which a .ics file is attached is opened using Gmail, it shows a preview of the event time. That preview is mostly appearing correctly, but occasionally, it shows the time advanced by 5:30 hours (Indian Standard Time). At other times, while the preview is wrong, when we proceed to add the event to our calendar, it shows the correct time.
This inconsistency might mean that I'm using a time format which is not officially supported by ICS standard (or Gmail).
This is my file:
BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
PRODID://<Org. Name>/<Event Name>//EN
UID:<something>
BEGIN:VEVENT
DTSTART:20190622T090000+05:30
DTEND:20190622T120000+05:30
SUMMARY:<Summary>
ORGANIZER;CN=<Org. Name>:<Org. EmailID>
LOCATION:<Location>
DESCRIPTION:<Text>
END:VEVENT
END:VCALENDAR
Some have suggested that we use an Olson identifier like this:
DTEND;TZID=Asia/Kolkata:20140606T180000
DTSTART;TZID=US-Pacific:20140606T170000
But what is the official way to specify time in an ics file so that Google preview and calendar reads it correctly? Should I be specifying the time in GMT instead? (I think it shouldn't make a difference)
And what is wrong with the style I have used (20190622T090000+05:30)
I recommend you to follow the standard directives of ical. With that, you are sure that it will work with google:
https://icalendar.org/iCalendar-RFC-5545/3-2-19-time-zone-identifier.html
For this case, I suggest you the Olson identifier as yourself suggested.
DTSTART;TZID=America/New_York:19980119T020000
I have the following link for a user to create a Google calendar event
https://calendar.google.com/calendar/render?action=TEMPLATE&text=Your+Event+Name&dates=20140127T224000Z/20140320T221500Z&ctz=America/Los_Angeles&details=For+details,+link+here:+http://www.example.com&location=Waldorf+Astoria,+301+Park+Ave+,+New+York,+NY+10022&sf=true&output=xml#eventpage_6
I originally found this out using the example from Link to add to google calendar
The issue I am having is to do with the time part of the URL which is
&dates=20140127T224000Z/20140320T221500Z
to break this down the format for this in which Google uses to determine the start/end date and time is
Ymd\\THi00\\Z
So you understand Google uses GMT as a standard time in the url and converts it correctly according to the users settings in their Google account. For instance (GMT-07:00) Pacific Time
So let's take just the start time of this URL which is
224000 which is Hi00 or Hour:Minutes:Seconds
In my Google calendar, my timezone settings are set to Pacific which is -7. Converting 224000 GMT to -7 Pacific you get 154000 which should be 3:40 PM
Problem is when you click the link, (if you are pacific) it is showing me the start time as 2:40 PM
What's even weirder is the end time which is 221500 shows as 3:15 PM. The end time hour is still the same as the start time but shows 1 hour ahead. I get that Google is probably assuming that I mean 1 hour ahead and makes that change for me, OR by default Google probably adds 1 hour more from the start time automatically.
I am not sure if I am understanding the format Google uses GMT in the URL or there is an issue with my coding and how I am representing that. Anyone have any info on this?
You may want to check this page wherein it discussed how Google Calendar uses time zones. As mentioned,
When you create an event, you'll see it in your local time zone. It will also show up in the local time zones for anyone you invite, even if they're in a different time zone.
And, on Daylight savings time:
Google Calendar uses Coordinated Universal Time (UTC) to help avoid issues with daylight savings time.
When events are created, they're converted into UTC, but you'll always see them in your local time.
If an area switches their time zone, events created before we knew about the change might be in the wrong time zone.
With this, you may want to try the given workarounds in this thread and see if it will help you.
I am generating an iCalendar feed which will be consumed by other web services. I am wondering if iCalendar file format allows overlapping events, for example:
BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
PRODID:-//Fabricam Calendar//EN
BEGIN:VEVENT
UID:EVENT1#fabricam.com
DTSTART:20151009T170000
DTEND:20151011T110000
SUMMARY:Event 1 -- Oct 09 to Oct 11
END:VEVENT
BEGIN:VEVENT
UID:EVENT2#fabricam.com
DTSTART:20151010T170000
DTEND:20151020T110000
SUMMARY:Event 2 -- Oct 10 to Oct 20
END:VEVENT
END:VCALENDAR
Note that the second event starts in the middle of first event. The feed validates perfectly. However when I import it in Google calendar then some/all events with overlapping dates are skipped.
I am wondering if this behavior described in specs. Or should I test all feed consumers to see how they behave?
There is definitely nothing that would say that you can't have overlapping events. It actually happens all the time !
On the other hand, you have all your DTSTART/DTEND in floating time (as opposed to UTC or local time with timezone). So the events may not end up where you think they are / Google may not like this type of events, especially given that they span multiple days.
On our web app in ASP, we have a module that generates VCS files to be imported into your calendar.
This works fine if the client is on the same zone as us (GMT).
But If I create an event which starts at 9am in UTC-01 for example, I still get the event as starting at 9am UTC/GMT, it's like it won't read the TZOFFSET
This is the VCS generated. In this example the event is supposed to take place Dec 30th 2011 9am-10am in UTC-05 (New York). If I leave my time zone as GMT, I get the appointment as 9am-10am instead of calculating the time difference. Even if I change my timezones it always calculates the difference against GMT and not the Time Zone where the event is taking place.
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:-Microsoft
VERSION:2.0
BEGIN:VTIMEZONE
TZID:America/New_York
TZ:UTC-05
X-MICROSOFT-CDO-TZID:10
BEGIN:STANDARD
DTSTART:20111230T090000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
BEGIN:DAYLIGHT
DTSTART: 20111230T090000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20111116T100300Z
DTSTART;TZID=America/New_York:20111230T090000
SUMMARY;ENCODING=QUOTED-PRINTABLE:TEST
UID:12347a7833h
ORGANIZER;CN=Test:MAILTO:test#test.com
LOCATION;ENCODING=QUOTED-PRINTABLE:Hall A
DTEND;TZID=America/New_York:20111230T100000
DESCRIPTION;ENCODING=QUOTED-PRINTABLE:
SEQUENCE:0
PRIORITY:5
TRANSP:OPAQUE
CATEGORIES:Test
CLASS:PUBLIC
END:VEVENT
END:VCALENDAR
I've been googling around for several days now and can't seem to find any good documentation on how to generate VCS correctly.
Any help will be great!
Thanks,
Federico
Here's the text from the blog post I mentioned (which is no longer available):
==========
Here's the issue: If you search Google on how to create an Outlook Calendar email notification/ics file, you might stumble across this page which has a generic template you could use. Or you might send yourself an invitation and look at the source code for the ICS file.
Either way you'll see the following lines within the VTIMEZONE block:
TZID:(GMT-05.00) Eastern Time (US & Canada)
X-MICROSOFT-CDO-TZID:10
Notice the strange X-MICROSOFT-CDO-TZID line... it simply has a number, "10". Well, according to Microsoft the number 10 represents the Eastern Time Zone here in America. Searching Google you might see more examples of this strange number/location mapping but you'll be hard pressed to find a complete listing of all the mappings. 11 is Central Time, 12 is Mountain Time, 13 is Pacific Time, but 38 is Mountain Time for Arizona...?
After much research (and a phone call to a MSFT employee), we found this document deep within a MSDN website: http://msdn.microsoft.com/en-us/library/aa563018(loband).aspx
It documents all the time zone "numbers" you'll need to use in order to correctly set up an ICS file.
==========
Cheers!
I'm sure the OP has solved this already, but here's a great blog post that discusses the proprietary "X-MICROSOFT-CDO-TZID" tag that Microsoft uses to help with timezone interpretation in Outlook: http://hello-dot-wordpress.blogspot.com/2009/10/my-guide-to-x-microsoft-cdo-tzid.html
Edit: Updated Link.