Lester > The problem I had in the past was with meetings being moved over a DST > boundary. And this was in a SINGLE timezone. The software was normalizing > everything to UTC time, so that it could be displayed in local time of the > client, but what was forgotten in the software was which timezone was used > to store the data. It was JUST stored as an offset, so when the meeting > moved the change in DST was missed.
Missed how? That seems to be an application implementation issue/bug related to how it calculated the local time, not an issue of use of UTC offset. > The fact that some timezones have > DST changes and some do not means that one needs to store the the actual > rule used and not just an offset. But more than that, one HAS to remember > the version of the rule being used! Let's say we do that. Further, let's say that tomorrow the New York state announces that starting next year there will be no DST. So, the definition of the "America/New York" time region is affected, which as a timezone, is used by millions of people in the Eastern US, so all their events would be affected. What would you expect a user/developer/the system do to handle this change? For both pre-change and post-change events? Sean P.S. Lester like you, our application space needs to consider time zones. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
