History of Reliance on timezone data

<p>Following an of-list post to one on the tz list a thought cam to me about the idea of loosing timezones. I started working with what was &#39;tikiwiki&#39; back then and ported it to Firebird which was still Interbase back then so some time ago. Firebird only ever worked with &#39;local&#39; time internally which was naturally UTC and we have always simply used tz data to provide the correct time display to users ... despite the simple fact that browsers do not ACTUALLY provide tz only some random current time offset so one could ONLY work with users who had already logged in and set their tz.</p>

<p>tikiwiki stored everything in &#39;user local time&#39; and had some cleaver juggling to return what was purported be UTC, but was wrong more often than not, usually when looking at the calendar 6 months later. So my first change for my own port was to switch to only using UTC as that was natural for Firebird, and then one only translated a users local time to UTC. This still had the same problem if the user was not logged in you still had no DST data to work with, but you just blocked those sort of problem conversions until the user set a current tz. This is still the case even today. NOBODY seems to be bothered that the browser tz tag is simply unusable? The current random changing of the key data we can use is what is so aggravating today since there is little coroberating proof to the changes?</p>

<p>What I have realised is that it&#39;s the obsesion of using timezone as an integral part of a timestamp which is where everything goes wrong and that there is little point to doing that. We have avoided adding timezone to the Firebird date datatype and the reasoning behind that is even more enhanced today. The only date value that is needed is the UTC normalized &#39;number&#39; as it is simply how that is displayed which is of any interest. It&#39;s a discussion that has been had before, and yes there need to store a timezone in the same record as the date stamp, but that is only to identify the location at which the date is recorded. This way one only ever needs the timezone data to display a date. The default being UTC where we have no identifying tz, but normally it will be the location tz or the user&#39;s tz depending on what information is displayed.</p>

<p>There has been comment on the situation where you do not know the tz for a date, but that simply means that tz is &#39;Unknown&#39; rather than UTC. That just flags that the date&nbsp; &nbsp;</p>