O.P. RE: Attaching timezone attributes to my chat list - A Suggestion
Sure... requesting information from a pseudo-standardized source is one implementation... not one I'd be in favor of... simply because of the tradeoffs... One that comes to mind is the dependency on a data source that could very easily go away. Another... data formats can be independently changed without notice.
I think that the basic time calculations are fairly straight forward - the time (without considering DST) is a predictable calculation from a known standard. DST is optionally applicable and when it is (applicable) it's basically plus or minus one hour from the current time depending on whether or not the date of the calculation falls inside or outside the DST window. The data storage requirements are relatively small...
You'd need:
byte gmtOffHrs; // range: 0 to 14 (hours)
byte gmtOffMin; // range: 0 or 30 (minutes)
boolean plusMinus; // 0 = +GMT, 1 = -GMT
boolean useDST; // 1 = DST, 0 = no DST
unsigned long dstBegin; // GMT timestamp when DST begins
unsigned long dstEnd; // GMT timestand when DST ends
I may have left something out... but I don't see any real advantage in requesting the data from an external source when the requirements for the calculation is so small...
I would disagree that the implementation would be difficult (I'm not saying it's trivial either). I also disagree that there is a "lot of user input" - I don't see it as any more than is required for a basic Windows installation... I also disagree that it would need to be re-entered every year... most DST windows have remained the same for years... but for the sake of argument let's assume that the dates do change... I don't see it as a show stopper.
Life would be much easier if I had the source code.
|