Web server"s "local" time in auth ticket. Is it realy true?

Hi,

According to the on-line docs, the expiry stored in the authentication
ticket (form auth) is an absolute date and time value in server's LOCAL time
instead of UTC. I could not believe what I was reading. It is really
shocking to learn that someone would go for that kind of design which opens
'a can of worms' related to DST.
Does anyone know what the rationale behind the design was? Or is this just
a sloppy design.

Thanks,
Bogdan

RE: Web server"s "local" time in auth ticket. Is it realy true?

yes, its true. as the time is only used server side, it makes little
difference. sure its a little sloppy, and the daylight saving time changes
will extend, or expire a cookie once a year, but really its no biggie.

-- bruce (sqlwork.com)


"bogdan" wrote:

> Hi,
>
> According to the on-line docs, the expiry stored in the authentication
> ticket (form auth) is an absolute date and time value in server's LOCAL time
> instead of UTC. I could not believe what I was reading. It is really
> shocking to learn that someone would go for that kind of design which opens
> 'a can of worms' related to DST.
> Does anyone know what the rationale behind the design was? Or is this just
> a sloppy design.
>
> Thanks,
> Bogdan
>
>
>
>

Re: Web server"s "local" time in auth ticket. Is it realy true?

Actually, it is twice a year :)

But you are right, it is not a biggie in most of the cases. Still, it
creates unnecessary issues that could've been avoided with no more/less
coding.
For example, with expiration time set to 60 minutes or less, transition from
standard to DST will expire all cookies of connected users regardless if
they are on-line few seconds or 1/2 hour. This must be an issue for busy
sites. The last thing one need is to have his/her site labelled as 'not
reliable' during standard->DST transition.

"bruce barker" wrote in message
news:2DB9B537-141D-4078-BFA7-E1D8C6CF30D6@microsoft.com...
> yes, its true. as the time is only used server side, it makes little
> difference. sure its a little sloppy, and the daylight saving time changes
> will extend, or expire a cookie once a year, but really its no biggie.
>
> -- bruce (sqlwork.com)
>
>
> "bogdan" wrote:
>
>> Hi,
>>
>> According to the on-line docs, the expiry stored in the authentication
>> ticket (form auth) is an absolute date and time value in server's LOCAL
>> time
>> instead of UTC. I could not believe what I was reading. It is really
>> shocking to learn that someone would go for that kind of design which
>> opens
>> 'a can of worms' related to DST.
>> Does anyone know what the rationale behind the design was? Or is this
>> just
>> a sloppy design.
>>
>> Thanks,
>> Bogdan
>>
>>
>>
>>