I have been trying to get an ICS file with a floating timezone setup. Research suggests that floating timezones are not recommended, but my client has specifically asked that a user downloading the ICS file in the UK and one in the US will both see the same time.
The code I have is as follows (minus the message body);
BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 14.0 MIMEDIR//EN
VERSION:2.0
METHOD:PUBLISH
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VTIMEZONE
TZID:GMT Standard Time
BEGIN:STANDARD
DTSTART:16011028T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:+0000
TZOFFSETTO:-0000
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010325T010000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZOFFSETFROM:-0000
TZOFFSETTO:+0000
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
CLASS:PUBLIC
CREATED:20150609T083427Z
DESCRIPTION:Testing Tuesday 09/06/2015 – 11.00-11.30\n
DTEND;TZID="GMT Standard Time":20150609T113000
DTSTAMP:20150609T083427Z
DTSTART;TZID="GMT Standard Time":20150609T110000
LAST-MODIFIED:20150609T083427Z
LOCATION:LA
PRIORITY:5
SEQUENCE:0
SUMMARY;LANGUAGE=en-gb:Test Short Event
TRANSP:OPAQUE
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MS-OLK-AUTOFILLLOCATION:FALSE
X-MS-OLK-CONFTYPE:0
BEGIN:VALARM
TRIGGER:-PT15M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR
I have set my computer's timezone to Phoenix (UTC -07:00), and opening this ICS file in Outlook works in that the time it displays is 11:00-11:30 as I would hope. However, Outlook also opens up the timezone drop downs displaying 'Dublin, Edinburgh, Lisbon, London'. If this course was being run in the US then I think this would be confusing for users.
I have tried removing all of the VTIMEZONE section, and the TZID references within DTSTART and DTEND, or just removing one or the other, or changing them the TZID to TZID:America/Phoenix, or adding a Z to the times, but all of these seems to give me erratic timings. However, it does remove the timezone drop down in Outlook!
So my questions are;
1. Is there a way I can tell Outlook to not open the Timezone drop down from within this ICS file?
2. Is there a better way for me to do this, setting the exact time of the course and ability to download it anywhere in the world with the same set time for the course?
Thanks, and I hope that all I have written makes sense. I have done hours of research into this, but I just seem to be going round in circles!
The standard way to represent floating events corresponds to your second description (i.e. remove all references to TZID). In your case something like:
DTSTART:20150609T110000
DTEND:20150609T113000
What was the outcome of such an event on the Outlook side ?
Some more research (yawn) has suggested that this is an Outlook issue, and that they do not follow the ICS guidelines for floating timezones;
MS Outlook incorrectly interprets ICS files in local time: daylight savings time overcorrection
So, now I am thinking that the only way around this is to gather the timezone of the person who is accessing the ics file, and take away the time difference from the ICS file time. So, if the course is being run at 11am, and someone in California (UTC -08:00) picks it up, then I will have to tell the file to input the course as starting at 7pm, so that it will be pulled into that user’s Outlook displaying the correct time of 11am. Or I think that’s how it would work anyway. More tinkering required.
Related
In some cases, the bot may have knowledge of the user's timezone. Is there a way to pass this knowledge to the bot framework so that it can handle certain date forms correctly - e.g. "tomorrow" & "yesterday"? Even things like "next friday" are sometimes sensitive to the timezone.
Currently, it appears that these are handled assuming the user's timezone offset is zero.
It seems that the chronic parser is unreachable so you can't really change anything to that. I see 3 solutions.
Solution 1: Create your own RecognizeDateTime class to work with utc time or however you want.
Solutions 2: When you get the date (in the validation method for example) add the utc offset to the time. This will preserve the right date, for utc times and local times.
dateTime += TimeZone.CurrentTimeZone.GetUtcOffset(dateTime);
solution 3: When the datetime is created by using a string like "yesterday", the day is correct but the time defaults to 00:00 or 12AM. To make this less sensitive you can just add 12 hours to the UTC time. This will preserve the day in almost all timezones. (All timezones above 12+ will have a problem. Luckily there aren't many people there.) (This is the solution I'm currently using for one of my solutions)
I have a .ics file with properly formatted (validated) data, containing 2 events. When I try to import it into the Calendar application on MacOS, it only imports the second event, and ignores the first one. I saw an answer here but it doesn't quite address the question
BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
PRODID:-//Cal's Bridge Club//Calvin Calhoun//EN
BEGIN:VEVENT
UID:4696563918045184#m.com
ORGANIZER;CN=Calvin Calhoun:MAILTO:cal#m.com
DTSTAMP:20160215T142555Z
DTSTART:20160201T213000Z
DTEND:20160201T235500Z
SUMMARY:Night guys
TRANSP: TRANSPARENT
SEQUENCE:2
END:VEVENT
BEGIN:VEVENT
UID:4696563918045184#m.com
ORGANIZER;CN=Calvin Calhoun:MAILTO:cal#m.com
DTSTAMP:20160215T142555Z
DTSTART:20160229T213000Z
DTEND:20160229T235500Z
SUMMARY:Night guys
TRANSP: TRANSPARENT
SEQUENCE:2
END:VEVENT
END:VCALENDAR
The UID of both events is the same, which may be causing problems. Each event should have a unique UID.
Also, there is a space after the colon character in the TRANSP property, which shouldn't be there. This may cause problems too.
Perhaps this question should be broken up into two posts, but I currently have an API for a few business customers. I am currently using ISO 8601 timestamps with a UTC time zone to represent times. However, I don't like the idea of these timestamps being attached to any timezone because the times should be the same no matter what timezone you are in. 5PM UTC should be 5PM CST, etc...
I know that you can leave the Z off of an ISO timestamp, and it will be interpreted as whatever local time you are in. Is this ok practice? And if so, how do I do this in Ruby? I read the doc for the Time class and didn't see anything about this.
EDIT: Let me re-word this just a little bit, or atleast clarify something. The reason why I'm seeking timestamps that aren't attached to a timezone is exactly because I know that my client servers and API server will hardly ever match up. If a client is submitting an event with a time, that time needs to be ambiguously equal to the ambiguous locale specific to the event that the user is working on.
That's a mouthful...assume that I'm working on an event scheduler. Each event belongs to a storefront or location of a company. When times are being shown for a location, it is assumed that the times shown are in the timezone of the location, and for clarity's sake should never be shown at a time formatted to a user's local timezone. If I'm looking at the scheduler on the East Coast, but looking at events for locations on the West Coast, the times I should see should be local to the locations on the West Coast, not adjusted for my timezone.
I know a solution could be to simply store times with timezone information for the location its associated to. But the use case that a user would want to convert a time to their timezone is VERY rare, and I'd rather make implementing my API easier...this was actually my original implementation but implementing the API in many different environments and across multiple programming languages, it became clear that it is a hurdle to show times local to that timestamp's timezone for a lot of languages. If a user wanted to convert times to their local timezone I could easily store global timezone information for the location object itself.
I don't know what you mean by "the times should be the same no matter what timezone you are in. 5PM UTC should be 5PM CST, etc..". 5PM UTC clearly isn't 5PM CST!
Anyway, I don't think that what you are proposing is an ok practice. Suppose you leave off the Z and have a timestamp be interpreted as whatever local time you are in. Since this is a network API, the client and server might not be in the same timezone. When the client submits a "local" time, what does it mean? The local time on the client (if so, how does the server know what that is?)? The local time on the server? It's ambiguous. This is the crux of the reason why just about the only reasonable thing to do is to use UTC throughout.
What you can do is attach a timezone to a timestamp if it might be relevant. For example, "you should observe one minute of silence at 2012-11-10T22:00:00Z in honour of the soldiers who died in WW1" sounds weird because Rememberance Day isn't on November 10! "you should observe one minute of silence at 2012-11-11T11:00:00+13:00" sounds a lot better once you put that New Zealand time zone in there... In this case you can keep and timestamp (in either local or UTC) together with the timezone offset (e.g. store both of them together in your database).
It does, however, depend on what your times represent. For example, in "at equinoxes, sunset happens at 18:00" it makes sense to use an abstract time that isn't qualified with a timezone (it's true in every timezone, and/or you're talking about solar time). But attaching a date to this abstract time makes little sense, so I don't think you would be talking about ISO8601 in this case.
I have released an app which,. within its functionality displays date and time strings.
I am aware of the differing formats across cultures - however in some cases I had hardcoded values- for example I had gone with a custom format that was the 12 hr clock and showed AM/PM
I am now changing to use the standard date time format strings where possible, and so, for my times,I am now using the shortTimePattern.
What has surprised me is that for the US this shows as say 3:15PM but in the UK its 16:15 i.e the default there is the 24 hr clock.
Similarly in the US the long date includes the day of the week, where as in the UK it does not.
I am thinking that these defaults must be right and are what is expected within that country but is this really the case? I had no idea that the UK default would be a 24 hr clock. And, for those users in the UK who have the app, will they be annoyed when the next update shows the time in this format?
Interested in any opinions around this.
thanks
UK Users will not care between 24hr and am/pm (we don't talk to each other saying "It's fourteen hundred o'clock :P).
Dates are also fine unless you're using format of 12/02/12 as in the UK that's considered 12th Feb whereas in the states it's December 2nd.
This is not the place to solicit "opinions" on whether the behaviour provided by the framework is correct.
Assume that the framework is correct, unless you know otherwise.
If you want to know what your users will think you should ask them. (I assume that your users are not typical users of StackOverflow.) If you don't already have beta users in your target markets to ask then make the change to use the "standard" behaviour. If there is a problem your users will tell you.
Is thee some way of implementing a custom time zone in windows?
We have some PCs in Creston, British Columbia, Canada (Time zone exception) which stays the same time all year. So essentially, Creston does not observe a time zone. Can I implement this behavior in windowsÉ
I wrote a lengthy blog post about a similar problem we had: http://subjectivecoder.blogspot.com.au/2013/04/creating-custom-windows-timezones.html
The short version is that there is a spot in the registry which allows you to modify or create new time zones - but the registry format is fairly nasty.
Microsoft has a GUI tool called TZEdit which you can find here: http://support.microsoft.com/kb/914387 (scroll down to Method 2 and download TZEdit.exe).
If you want to see what's going on behind the scenes, I've published the source to the command line tool I built here: https://github.com/Rophuine/TimeZoneInfoGenerator (it's untested and quick-and-dirty but may help you understand what's going on, if you're interested).
Apart from daylight savings time, this is normal MST (UTC-0700), right?
Windows used to have a checkbox called something like "Automatically adjust the clock for daylight savings time". Maybe you can hunt that down. Even if there is no checkbox, chances are that the registry setting still exists.
The data is in: HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Time zones.
You can probably add your own zone.
Each zone has its own key. And they contain a lot of data. Some zones have a subkey Dynamic DST.
This is not exactly an answer, but you might consider trying to get Creston recognized as an official time zone. As for how exactly to do that... contact Microsoft, I guess, and ask where they get their time zone info from. Probably the closest thing to an official time zone database in computer programming is zoneinfo but I'm not sure if Microsoft uses it.
WARNING: You should be very careful about creating your own time zone, even if you think your systems are isolated.
This could cause problems with exchanging information with other systems, both from conversion errors as well as exception handling.
If the time zone you want is legally recognized, you should consider bothering your vendor to properly add you to the time zone repository they use.