Re: [RFC] HTTP timezone

On Monday 11 June 2007 16:05, Lester Caine wrote: > Timezone information is only of use for the CURRENT day - even if it is > wrong. It is ESSENTIAL that any changes also include the daylight saving > information. Since this is not included, all current sites handling event > related information in real time need to manually log a users PROPER time > and daylight saving information so that they know if 8AM today is the same > as 8AM tomorrow. Since HTTP is a query and response protocol, timezone information will be sent on each query. Lets say that it is XX of month Y 1:59 and that the timeoffset is changed at '2:00' by +1. A request sent at 1:59 will have an offset, lets say +0200. A request sent at 3:00 (that's one minute after 1:59) will have an offset of +0300. Full timezone information requires a POSIX 1003.1 timezone string that is quite complex to parse and support, since the server side script must be able to identify all of the available timezones. The first draft proposed this representation but was changed after the suggestions of ietf-http-wg mailing list people to only include the offset for simplicity. Timezone information is not meant to be stored as session information nor being used for anything else than one-time time/date representation. It is just a way for the client to say: If you're going to show me something that is time related then you should know that you should represent it using this offset from GMT. Something like the Accepted-Language header. Lets say you're viewing an MRTG generated graph. This graph uses the time as the X-axis value. Lets say that the server is in Greece where the offset is +0200 (+0300 during DST) and that the time is 14:10. The graph will end its X axis at the current time (14:10). Someone from the UK visits the graph page and he should see the same graph ending in 12:10 (UK is +0000). An incorrect timezone string will only result in 'bad' time representation which will be the case anyway (without TZ). There is no need to include the DST information since when on DST the client will be sending the propper offset. For example, EET+2EEST is +0200 during winter and +0300 during DST. Hope this clears things a bit... By the way, what makes you think that most people have an invalid timezone configured? Windows XP have NTP support that is enabled by default. Without a proper timezone this should result in an always invalid time. Linux and BSD systems have more experienced users that set their timezone correctly most of the time.