Policy on DST

[Lyos Gemini Norezel]

Paul W. Frields wrote:
> Every once in a while there's a random annoyance that seems worth
> bringing up and documenting for posterity.  Hopefully this is one of
> those times.
>
> In a nutshell: Does Fedora need a minimal policy for shifting the
> schedule of the #fedora-meeting channel to account for DST?
>
> Sticking with UTC sounds simple.  It's tempting to just use the geek
> perspective and say that's the standard, but this standard causes
> actual problems for humans, who govern their lives by local clocks.
> Moving meeting times back and forth in local time during the year
> seems arbitrary, and can create new conflicts that were carefully
> negotiated months before.  That's a barrier, and therefore my and the
> Board's job to assess and remove if possible.
>
> Most of our contributor base observes some sort of DST, so we should
> simply set dates on which the schedule shifts automatically.  We need
> not use USA standards for the date of the shifting.
>
> Practically speaking, the effect is that the meeting that happens at
> 11:00 local time during DST stays at 11:00 local time when DST ends,
> and vice versa.  That's much easier on humans than dickering around
> with UTC, especially when the tools we use for tracking our time
> already have the built-in capacity to change over from DST to non-DST.
>
> Why bring this up?  Take for example a Fedora team that meets in the
> hour between two other meetings in the channel.  The prior meeting
> moves its schedule in UTC (to stay at the same local time) and the
> following one does not, and thus shifts earlier by an hour when DST
> ends.  Suddenly there's a conflict.
>
> We could leave this up to individual teams to resolve when this
> happens, but wouldn't it be easier to just change one wiki page twice
> a year?
>
> And no, the decongestants haven't worn off yet, thanks for asking. ;-)
>   

I know I'm late on this one... but...


Why not just modify the page itself to allow the user to select the time 
zone/dst settings, if they choose?
The table could be, fairly simply, modified to recalculate times based 
on the time zone/DST selection... and a column could be added showing 
the DST difference.

ie.:
Group    Time/Date    DST Time/Date  etc...

This would highlight problem areas... and allow the groups to select an 
alternate time to compensate for the DST issues.


I'm not very familiar with Javascript and the like... but I know such 
things can be done...

Would this not solve much of the issues you raise?

Lyos Gemini Norezel