Difference between revisions of "Talk:SMTOFF"
(New page: ~~~~: I think the format for offset should be the more common hours and minutes format. Wikipedia (http://en.wikipedia.org/wiki/ISO8601#Time_offsets_from_UTC) and the Internet standard RFC...) |
m |
||
(12 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
[[User:Rmm|raphael]] 18:59, 3 February 2012 (UTC): I think the format for offset should be the more common hours and minutes format. Wikipedia (http://en.wikipedia.org/wiki/ISO8601#Time_offsets_from_UTC) and the Internet standard RFC 3339 use hours and minutes. | [[User:Rmm|raphael]] 18:59, 3 February 2012 (UTC): I think the format for offset should be the more common hours and minutes format. Wikipedia (http://en.wikipedia.org/wiki/ISO8601#Time_offsets_from_UTC) and the Internet standard RFC 3339 use hours and minutes. | ||
+ | |||
+ | |||
+ | [[User:DavidAcland|DavidAcland]] 12:39, 4 February 2012 (UTC) Thank you Raphael. I am very happy to use a standard although I do not know of any summertime offsets which are other than 1 hour, i.e. "01" or "+01:00". | ||
+ | |||
+ | But assuming that a nation was to specify a summer time difference of 1.5 hours, using the standard the encoder would have to put in: | ||
+ | |||
+ | +01:30 | ||
+ | |||
+ | Does this mean that the data type must now be "String"? | ||
+ | |||
+ | Reading the wiki entry on ISO8601 has introduced another slight concern in my mind. The Wikipedia entry on ISO8601 uses the word "Offset" to describe the differences between UTC and LT for both standard time and summer times. I fear we may confuse things, or some may be confused, if we also use "Offset" for the difference between summer time and standard time. To help clarity, perhaps we could use the word "Shift", or a better synonym if we can find one, for the difference between summer time and normal zone time, i.e. summerTimeShift; SMTSFT. | ||
+ | |||
+ | [[User:Jens|jens]] 12:44, 4 February 2012 (UTC) Hey guys, do we have areas where the summer time offset is not +1h? The attribute becomes superfluous if we couldn't find such an area. | ||
+ | |||
+ | [[User:DavidAcland|DavidAcland]] 13:12, 4 February 2012 (UTC) Not in our book, so I sort of agree. But there is no telling what some of the Islands in the Pacific will do to get ahead of the rest of the world. | ||
+ | |||
+ | Anyway where I am going on this at the moment is that there is a case to change categoryOfTimeZone [[CATTZN]] to Time offset, perhaps TIMOFF, to get into line with the language in ISO8601. Thereafter during the specified period of summer time, a shift of +1 hour is applied, or an alternative amount, if specified in the "Summer time shift" attribute, accepting it may never be used. | ||
+ | |||
+ | [[User:Jens|jens]] 14:47, 4 February 2012 (UTC) In that case I would recommend to use the Acronym UTCOFF rather than TIMOFF. SMTOFF and SMTSTA remain unchanged.<br> I see your point at summer time shift. I wouldn't have problems the keep "summer time shift" if everybody agree that this attribute may never be used. | ||
+ | |||
+ | [[User:Rmm|raphael]] 05:03, 5 February 2012 (UTC): I agree with Jens that UTCOFF is preferable to TIMOFF. (Or TimeZoneOffset/TZ_OFF, but UTCOFF is fine too.) | ||
+ | |||
+ | [[SMTOFF]] should be the time offset from UTC during summer time, i.e. for Germany UTCOFF would be +01:00 and SMTOFF would be +02:00. | ||
+ | |||
+ | The data type would be String and the format ±[hh]:[mm] (or ±[hh][mm]). End-users will see the definition or label of the attribute, which would make it clear whether it is standard time or summer time. | ||
+ | |||
+ | [[User:Jens|jens]] 10:39, 5 February 2012 (UTC) Yeap, that sounds reasonable now. CATTZN will be replaced by UTCOFF. That makes us and the use of the attribute more independant. SMTOFF should be used to specify the time offset from UTC in the summertime period specified by SMTSTA/END. | ||
+ | <br> David, can you do the finetuning? | ||
+ | |||
+ | [[User:DavidAcland|DavidAcland]] 11:42, 6 February 2012 (UTC) Good. This looks much more generic. I will make the changes and see where that brings us. | ||
+ | |||
+ | [[User:Rmm|raphael]] 19:29, 6 February 2012 (UTC): Suggest adding "from UTC" to the attribute name, please see the discussion on [[Talk:UTCOFF]]. (Or instead of changing the name, require that the value begin with "UTC" for both this attribute and [[UTCOFF]], thus: UTC+01:00, UTC-05:00) | ||
+ | |||
+ | Also, "added to UTC" instead of "applied to UTC" in the definition. |
Latest revision as of 19:48, 6 February 2012
raphael 18:59, 3 February 2012 (UTC): I think the format for offset should be the more common hours and minutes format. Wikipedia (http://en.wikipedia.org/wiki/ISO8601#Time_offsets_from_UTC) and the Internet standard RFC 3339 use hours and minutes.
DavidAcland 12:39, 4 February 2012 (UTC) Thank you Raphael. I am very happy to use a standard although I do not know of any summertime offsets which are other than 1 hour, i.e. "01" or "+01:00".
But assuming that a nation was to specify a summer time difference of 1.5 hours, using the standard the encoder would have to put in:
+01:30
Does this mean that the data type must now be "String"?
Reading the wiki entry on ISO8601 has introduced another slight concern in my mind. The Wikipedia entry on ISO8601 uses the word "Offset" to describe the differences between UTC and LT for both standard time and summer times. I fear we may confuse things, or some may be confused, if we also use "Offset" for the difference between summer time and standard time. To help clarity, perhaps we could use the word "Shift", or a better synonym if we can find one, for the difference between summer time and normal zone time, i.e. summerTimeShift; SMTSFT.
jens 12:44, 4 February 2012 (UTC) Hey guys, do we have areas where the summer time offset is not +1h? The attribute becomes superfluous if we couldn't find such an area.
DavidAcland 13:12, 4 February 2012 (UTC) Not in our book, so I sort of agree. But there is no telling what some of the Islands in the Pacific will do to get ahead of the rest of the world.
Anyway where I am going on this at the moment is that there is a case to change categoryOfTimeZone CATTZN to Time offset, perhaps TIMOFF, to get into line with the language in ISO8601. Thereafter during the specified period of summer time, a shift of +1 hour is applied, or an alternative amount, if specified in the "Summer time shift" attribute, accepting it may never be used.
jens 14:47, 4 February 2012 (UTC) In that case I would recommend to use the Acronym UTCOFF rather than TIMOFF. SMTOFF and SMTSTA remain unchanged.
I see your point at summer time shift. I wouldn't have problems the keep "summer time shift" if everybody agree that this attribute may never be used.
raphael 05:03, 5 February 2012 (UTC): I agree with Jens that UTCOFF is preferable to TIMOFF. (Or TimeZoneOffset/TZ_OFF, but UTCOFF is fine too.)
SMTOFF should be the time offset from UTC during summer time, i.e. for Germany UTCOFF would be +01:00 and SMTOFF would be +02:00.
The data type would be String and the format ±[hh]:[mm] (or ±[hh][mm]). End-users will see the definition or label of the attribute, which would make it clear whether it is standard time or summer time.
jens 10:39, 5 February 2012 (UTC) Yeap, that sounds reasonable now. CATTZN will be replaced by UTCOFF. That makes us and the use of the attribute more independant. SMTOFF should be used to specify the time offset from UTC in the summertime period specified by SMTSTA/END.
David, can you do the finetuning?
DavidAcland 11:42, 6 February 2012 (UTC) Good. This looks much more generic. I will make the changes and see where that brings us.
raphael 19:29, 6 February 2012 (UTC): Suggest adding "from UTC" to the attribute name, please see the discussion on Talk:UTCOFF. (Or instead of changing the name, require that the value begin with "UTC" for both this attribute and UTCOFF, thus: UTC+01:00, UTC-05:00)
Also, "added to UTC" instead of "applied to UTC" in the definition.