Re: [http-state] draft-ietf-httpstate-cookie-05 posted

Daniel Stenberg <daniel@haxx.se> Fri, 12 March 2010 09:47 UTC

Return-Path: <daniel@haxx.se>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5863A6A1A for <http-state@core3.amsl.com>; Fri, 12 Mar 2010 01:47:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zc4GTEPl1kQn for <http-state@core3.amsl.com>; Fri, 12 Mar 2010 01:47:36 -0800 (PST)
Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by core3.amsl.com (Postfix) with ESMTP id AC5183A6918 for <http-state@ietf.org>; Fri, 12 Mar 2010 01:47:35 -0800 (PST)
Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with ESMTP id o2C9laSr009660; Fri, 12 Mar 2010 10:47:37 +0100
Date: Fri, 12 Mar 2010 10:47:36 +0100
From: Daniel Stenberg <daniel@haxx.se>
X-X-Sender: dast@giant.haxx.se
To: "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>
In-Reply-To: <op.u9feulgkqrq7tp@acorna>
Message-ID: <alpine.DEB.2.00.1003121044450.28229@tvnag.unkk.fr>
References: <5c4444771003071050r3475798co95cc192d1f2e8190@mail.gmail.com> <op.u9dpzpdoqrq7tp@acorna> <5c4444771003101823u25842652o33b49b2be81f4cfc@mail.gmail.com> <alpine.DEB.2.00.1003112201360.25452@tvnag.unkk.fr> <op.u9feulgkqrq7tp@acorna>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
X-fromdanielhimself: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: http-state <http-state@ietf.org>
Subject: Re: [http-state] draft-ietf-httpstate-cookie-05 posted
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Mar 2010 09:47:37 -0000

On Fri, 12 Mar 2010, Yngve N. Pettersen (Developer Opera Software ASA) wrote:

>> Did you actually mean 2038 or is there any particular reason why there's a 
>> margin? See http://en.wikipedia.org/wiki/Year_2038_problem
>
> As I recall, at least some years ago, the documentation for several 32-bit 
> time_t functions I've used clearly specified that the conversion methods 
> to/from time_t were only valid until a specific date in 2036.

Can you or anyone else find/point to any closer details on this? I would like 
to see this somewhat explained next to the mention of the magic year 2036 as 
the 32bit limit does not really end until 2038 so I'm sure a few others than 
me who will suspect that 2036 might be a typo.

-- 

  / daniel.haxx.se