Subject: [Syntaxes] Generalized Time inconsistent with ASN.1

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 21 May 2003 12:42:48 +0200

ASN.1: X.680 (07/2002), section 42, says that 'Z' or timezone in
Generalized Time is optional, and if it is missing the time is local
time.  In the Syntaxes draft, 'Z' or timezone is mandatory.

-- 
Hallvard

---

From: "Steven Legg" <[email-masked]>
Date: Thu, 22 May 2003 16:40:04 +1000

Hallvard,

> time.  In the Syntaxes draft, 'Z' or timezone is mandatory.

It's mandatory in the syntaxes draft because it is mandatory in RFC 2252.
RFC 2252 disallows local time.

Regards,
Steven

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 22 May 2003 13:48:14 +0200

> RFC 2252 disallows local time.

I take it making the time zone optional is too big a change for ldapbis?
How about allowing servers to support local time, but not demainding it?

Or does X.500 disallow local time too?  I've looked at X.500, but all I
could find was X.520 6.3.3 'Generalized Time Match' which refers to
clauses 34.3 b) or c) of CCITT Rec. X.208 | ISO/IEC 8824.

-- 
Hallvard

---

From: Michael Ströder <[email-masked]>
Date: Thu, 22 May 2003 14:43:02 +0200

> How about allowing servers to support local time, but not demainding it?

Personally I'd like to leave it as is since it's well-defined and simple. 
What implementors definitely not need is dealing with yet another optional 
case. We have already way too many "OPTIONALs" in LDAP.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 22 May 2003 14:51:01 +0200

> I take it making the time zone optional is too big a change for ldapbis?

Another one:

user (sitting in Hongkong)
   --HTTP--> web gateway (Germany)
     --LDAP--> LDAP server (U.S.)

Which "local" time should be displayed to the user?

Ciao, Michael.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 22 May 2003 15:12:05 +0200

> Which "local" time should be displayed to the user?

Time without timezone, I think.  What it means is the user's problem, if
he uses it in such a context.  However, time without timezone can be
useful in genuinely local contexts.  For example, work hours here starts
at 8:00 local time all year, but which timezone that is varies due to
daylight savings time.

-- 
Hallvard

---

From: Michael Ströder <[email-masked]>
Date: Thu, 22 May 2003 15:47:48 +0200

Hallvard B Furuseth wrote:
 > Time without timezone, I think.

And how should generalizedTimeOrderingMatch be implemented in this scenario?

 >  What it means is the user's problem, if he uses it in such a context.

Sorry, does not make sense to me. Please leave it strictly as defined in 
RFC2252.

 > However, time without timezone can be useful in genuinely local contexts.

How about allow garbage in, produce correct output?
A server implementor MAY decide to accept attribute values for 
GeneralizedTime without time zone. But the server MUST return the attribute 
value with time zone set, the attribute value massaged according to some 
local time zone configuration.

 > For example, work hours here starts

Can you imagine all the weird postings to mailing lists with people asking 
how that is supposed to work? We should try to avoid adding yet more blurred 
definitions like the "minimum upper bound" in attribute type declaration...

Ciao, Michael.

---

From: [email-masked] (Mark C Smith)
Date: Thu, 22 May 2003 09:57:44 -0400

> at 8:00 local time all year, but which timezone that is varies due to

I do no think we should make timezone optional. In my opinion, that is a 
very bad idea and will likely reduce interoperability among LDAP 
implementations. I agree with Michael that things are nice and simple 
and well understood as currently specified.

-- 
Mark Smith
Netscape Directory Product Development
My words are my own, not my employer's.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 22 May 2003 16:27:10 +0200

> And how should generalizedTimeOrderingMatch be implemented in this

Comparing local time with timezoned time would be undefined.  Well, the
server could get clever and decide that it's defined if the difference
is the same whatever timezone is used, but I see no need for such
cleverness.

Except I seem to be outvoted on this one anyway, so never mind.

> How about allow garbage in, produce correct output?  A server
> implementor MAY decide to accept attribute values for GeneralizedTime
> without time zone. But the server MUST return the attribute value with
> time zone set, the attribute value massaged according to some local
> time zone configuration.

I don't think so.  From the user's point of view, software that tries to
be smart and silently adds 'missing' information to user input all to
often results in correct data in, garbage out.
		
-- 
Hallvard