Subject: [netmod] date-and-time canonicalization (option #3)

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Aug 2009 00:03:25 +0200

During the Stockholm IETF meeting, the canonicalization of
data-and-time was discussed. The current text says that NETCONF
server must return date-and-time values in UTC format. That is,
I can configure

    2009-08-09T23:08:00+02:00

and the server will return the configured time in UTC using the "Z"
format:

    2009-08-09T21:08:00Z

We discussed to what extend this behaviour is desirable and there was
rough consensus in the meeting room to stick to the current rules.

I can easily see that certain NETCONF users will be pretty surprised
by this behaviour (especially enterprises operating local networks in
just one time zone) while others will find it cool (operators of
networks spanning the globe). So I am wondering whether we can find a
solution that makes both "camps" happy. So far, we considered the
"always UTC" option and the "server remembers configured time offset"
options. Here is the "everything is relative to the servers notion of
its time zone offset" proposal:

  The canonical format for date-and-time values is the format with a
  numeric time zone offset that is calculated using the device's
  configured known offset to UTC time. A change of the device's offset
  to UTC time will cause date-and-time values to change accordingly.
  Such changes might happen periodically in case a server follows
  automatically daylight saving time (DST) time zone offset changes.

This is a departure from the XSD dateTime rules (XSD requires the "Z"
format) but this approach has the advantage that operators deploying
NETCONF servers can configure the time zone and thus decide themselves
whether they like all dates to be returned in UTC or in a local time
zone. As a side effect, a server returning

    2009-08-09T23:08:00+02:00

indicates that the server's time offset is +02:00 at the time when the
response was generated.

Comments?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Phil Shafer <[email-masked]>
Date: Mon, 10 Aug 2009 09:28:42 -0400

Juergen Schoenwaelder writes:
>solution that makes both "camps" happy.

Global operators (and many national multi-time-zone ones) don't
configure a time zone on the box, defaulting it to UTC.  So this
proposal (follow the configured time zone) should make everyone
happy.

Thanks,
 Phil

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 10 Aug 2009 13:11:47 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: <[email-masked]>
> Sent: Sunday, August 09, 2009 3:03 PM
> Subject: [netmod] date-and-time canonicalization (option #3)
...
> indicates that the server's time offset is +02:00 at the time when the
...

For some use cases this would be desirable, for others not.  Sometimes
a time or schedule really needs to be in terms of local clock time.  On the
one side, consider intrusion detection sensors that need to be in harmony
with an office's local hours of operation.   On the other side, consider backup
runs scheduled to avoid overtaxing an enterprise's global network.  The former
absolutely needs to take local daylight savings time changes into account.
The latter probably should not.

There really is a semantic difference between "schedule according to local
clock time" and "schedule for purposes of global coordination".  A model
that loses that semantic will shortchange one or the other.

I *do* think this issue can be separated from that of canonicalization.  After all,
it's really a matter of the semantics of the bit of configuration data.  If the goal is
to handle both semantics in a single data type, then this bit needs to show up
in the representation.  If we decide that the difference in semantics merits having
two distinct types (which happen to look very much alike), then there's no need
for in in the representation.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Aug 2009 14:54:08 +0200

On Mon, Aug 10, 2009 at 10:11:47PM +0200, Randy Presuhn wrote:
> For some use cases this would be desirable, for others not.
> Sometimes a time or schedule really needs to be in terms of local
> clock time.  On the one side, consider intrusion detection sensors
> that need to be in harmony with an office's local hours of
> operation.  On the other side, consider backup runs scheduled to
> avoid overtaxing an enterprise's global network.  The former
> absolutely needs to take local daylight savings time changes into
> account.  The latter probably should not.
> 
> I *do* think this issue can be separated from that of
> canonicalization.  After all, it's really a matter of the semantics
> of the bit of configuration data.  If the goal is to handle both
> semantics in a single data type, then this bit needs to show up in
> the representation.  If we decide that the difference in semantics
> merits having two distinct types (which happen to look very much
> alike), then there's no need for in in the representation.

Following RFC 3339, you can specify unknown timezone by using:

    2009-08-09T23:08:00-00:00

The only sensible interpretation of this I can come up with on the
device is local time. So it is possible to make a distinction.

I am tempted to actually allow the short-hand notation

    2009-08-09T23:08:00

for this and to make this the canonical format (that is something
configured as 2009-08-09T23:08:00-00:00 will be returned as
2009-08-09T23:08:00) since it seems to be easier to read.

Further comments?

/js