[英]Is there any RFC standard that defines which timezone wins for recurring events if daylight savings occur?
How does the iCalender file look like if I want the austrian timezone to "win"?如果我希望奥地利时区“获胜”,iCalender 文件会是什么样子? And is this even possible according to a RFC standard?
根据 RFC 标准,这甚至可能吗? If the austrian timezone "wins", then the time changes and the video calls are 1 hour later at October 30th:
如果奥地利时区“获胜”,则时间会更改,视频通话将在 10 月 30 日晚 1 小时:
Is it enough to simply include the timezone in DTSTART
like this?像这样简单地将时区包含在
DTSTART
中就足够了吗? If yes, which RFC defines it?如果是,哪个 RFC 定义了它?
BEGIN:VCALENDAR
BEGIN:VEVENT
DTSTART;TZID=Europe/Vienna:20221029T140000
RRULE:FREQ=DAILY;COUNT=2
END:VEVENT
END:VCALENDAR
And if there is a RFC which defines how the iCalendar file must look like, is there also an RFC that defines that every implementation has to calculate the single dates for this iCalendar file at 13:00 UTC, 14:00 in Austria and 18:30 in India as soon as the DST change occurs?如果有一个 RFC 定义了 iCalendar 文件的外观,是否还有一个 RFC 定义了每个实现都必须在 13:00 UTC、奥地利 14:00 和 18:00 计算此 iCalendar 文件的单个日期:一旦 DST 更改发生,印度 30?
The Time Zone Identifier
is defined in section-3.2.19 of RFC5545 . Time Zone Identifier
在RFC5545的第 3.2.19 节中定义。
The example you give is appropriate for TZID in a DTSTART.您给出的示例适用于 DTSTART 中的 TZID。 See the comment in the same section 3.2.19
见同节3.2.19的评论
This parameter [TZID] MUST be specified on the "DTSTART", "DTEND", "DUE", "EXDATE", and "RDATE" properties when either a DATE-TIME or TIME value type is specified and when the value is neither a UTC or a "floating" time [...] following are examples of this property parameter:
当指定了 DATE-TIME 或 TIME 值类型并且值既不是UTC 或“浮动”时间 [...] 以下是此属性参数的示例:
DTSTART;TZID=America/New_York:19980119T020000 DTEND;TZID=America/New_York:19980119T030000
DTSTART;TZID=美国/纽约:19980119T020000 DTEND;TZID=美国/纽约:19980119T030000
It should be noted the standard mandates the definition of the TZID in the same file inside a VTIMEZONE
component.应该注意的是,标准要求在
VTIMEZONE
组件内的同一文件中定义 TZID。
An individual "VTIMEZONE" calendar component MUST be specified for each unique "TZID" parameter value specified in the iCalendar object.
必须为 iCalendar object 中指定的每个唯一“TZID”参数值指定一个单独的“VTIMEZONE”日历组件。
as such implicit references to TZID often work but aren't compliant to the standard.因为对 TZID 的这种隐式引用通常有效但不符合标准。
The standard does not specify that client has to compute the single dates for this iCalendar file at 13:00 UTC, 14:00 in Austria and 18:30 in India as soon as the DST change occurs?
该标准未指定客户必须
the single dates for this iCalendar file at 13:00 UTC, 14:00 in Austria and 18:30 in India as soon as the DST change occurs?
rather the client has to compute when the event has to occur as a function of which timezone it is defined in and then compare to local time and see if they match.相反,客户端必须计算事件何时发生,作为定义时区的 function,然后与本地时间进行比较,看看它们是否匹配。
The easier way to see it is to say the clients computes the datetime of all events in UTC time taking into account the TZID it is define in and checks current time vs UTC to see if an alarm has to be triggered.更简单的理解方式是说客户端计算 UTC 时间中所有事件的日期时间,同时考虑到它在其中定义的 TZID,并检查当前时间与 UTC 以查看是否必须触发警报。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.