Difference between revisions of "Talk:SMTOFF"
m |
|||
Line 25: | Line 25: | ||
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. | 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? |
Revision as of 10:39, 5 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?