Subject: [netmod] ietf-system: timezone-utc-offset

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Fri, 22 Jun 2012 12:53:30 +0000

Currently timezone-location and timezone-name are defined in the YANG modle with "if-feature", but timezone-utc-offset is not.  I think that this should also be gated on an if-feature.  If I plan on having timezone support in my product, I want to ensure that daylight savings time is properly reflected.  To do this I'd use the zoneinfo database or the like.  If I also needed to support the manual setting of time offsets, I'd need to put custom code everywhere in the system where a time is calculated rather than just relying on the standard system APIs to give me the current and correct time.

Without having this as a feature you are implying that I MUST support this additional functionality if I want to use the ietf-system model.

Perhaps a config false leaf that returns the current UTC offset would be useful too.  That way if you set the timezone via a name, you can also check to ensure that it is really the UTC offset you are expecting.

Thanks,

Jeff Lange
Lead Software Engineer
GE Energy Services
Digital Energy

T +1 585 242 8375
F +1 585 241 5590
[email-masked]
www.GEDigitalEnergy.com

175 Science Parkway
Rochester, NY 14620 United States

GE imagination at work

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Jun 2012 07:48:16 -0700

On Fri, Jun 22, 2012 at 5:53 AM, Lange, Jeffrey K (GE Energy) <
[email-masked]> wrote:

>  Currently timezone-location and timezone-name are defined in the YANG
> modle with “if-feature”, but timezone-utc-offset is not.  I think that this
> should also be gated on an if-feature.  If I plan on having timezone
> support in my product, I want to ensure that daylight savings time is
> properly reflected.  To do this I’d use the zoneinfo database or the like.
> If I also needed to support the manual setting of time offsets, I’d need to
> put custom code everywhere in the system where a time is calculated rather
> than just relying on the standard system APIs to give me the current and
> correct time.****
>
> **
>

why is this leaf so hard to support?

> **
>
> Without having this as a feature you are implying that I MUST support this
> additional functionality if I want to use the ietf-system model.****
>
> **
>

that's how YANG conformance works

> **
>
> Perhaps a config false leaf that returns the current UTC offset would be
> useful too.  That way if you set the timezone via a name, you can also
> check to ensure that it is really the UTC offset you are expecting.****
>
> **
>

I don't think any changes are needed.
A device should support setting the timezone.
The config-true leaf also returns the current value.

Andy

> **
> Thanks,****
> ** **
> *Jeff Lange*
> T *+1 585 242 8375*
> F *+1 585 241 5590*
> ****
> ** **
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
>

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Fri, 22 Jun 2012 15:04:12 +0000

>why is this leaf so hard to support?

Because by allowing someone to specify a UTC offset, you are losing the ability to take advantage of setting the timezone via the tzdatabase which means that if you have no way of automatically adjusting for daylight savings time.   Sure you could 'guess' the timezone based on the UTC offset, but that is hardly an exact method.

I don't want to have to write a whole bunch of utility code just to get the current time when all the standard system APIs know how to use /etc/localtime

-Jeff

Jeff Lange
Lead Software Engineer
GE Energy Services
Digital Energy

T +1 585 242 8375
F +1 585 241 5590
[email-masked]
www.GEDigitalEnergy.com

175 Science Parkway

GE imagination at work

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Jun 2012 17:22:30 +0200

> Because by allowing someone to specify a UTC offset, you are losing the ability to take advantage of setting the timezone via the tzdatabase which means that if you have no way of automatically adj…

If someone configures lets say UTC offset +1, he likely wants exactly
that and does not want any daylight savings time changes.

> I don't want to have to write a whole bunch of utility code just to get the current time when all the standard system APIs know how to use /etc/localtime

I do not think you have to write lots of complicated code. On Unix
systems, library functions control which timezone your process lives
in. And there are even zone files for GMT+1, GMT-1, ... hence setting
a system's time to UTC +1 is also not a big deal.

/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: Andy Bierman <[email-masked]>
Date: Fri, 22 Jun 2012 08:33:53 -0700

Hi,

I can see your point.
The intent was to make timezone-utc-offset mandatory as a fallback.
I can see making this optional with a YANG feature.
There is no way in YANG to say "the server MUST implement 1 of
these 3 features" except in a random description-stmt.
By definition, all YANG features are purely optional.

Andy

On Fri, Jun 22, 2012 at 8:04 AM, Lange, Jeffrey K (GE Energy) <
[email-masked]> wrote:

> Because by allowing someone to specify a UTC offset, you are losing
> the ability to take advantage of setting the timezone via the tzdatabase
> which means that if you have no way of automatically adjusting for daylight
> savings time.   Sure you could 'guess' the timezone based on the UTC
> offset, but that is hardly an exact method.
>
> I don't want to have to write a whole bunch of utility code just to get
> the current time when all the standard system APIs know how to use
> /etc/localtime
>
> -Jeff
>
> Jeff Lange
> Lead Software Engineer
> GE Energy Services
> Digital Energy
>
> T +1 585 242 8375
> F +1 585 241 5590
> [email-masked]
> www.GEDigitalEnergy.com
>
> 175 Science Parkway

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Fri, 22 Jun 2012 15:41:41 +0000

> If someone configures lets say UTC offset +1, he likely wants exactly that and does not want any daylight savings time changes.

I can buy that, but perhaps there should be some description text stating that if the device supports automatic DST adjustment, setting the timezone via the utc-offset will prevent DST adjustments.  Or even some way of configuring if you want the device to observe DST or not (perhaps that's just setting via the utc-offset).. and in that vein, should there be a config false or a feature that says if a device can even support DST?

>
> > I don't want to have to write a whole bunch of utility code just to 
> > get the current time when all the standard system APIs know how to use 
> > /etc/localtime
> 
> 
> I do not think you have to write lots of complicated code. On Unix systems, library functions control which timezone your process lives in. And there are even zone files for GMT+1, GMT-1, ... hence setting a system's time to UTC +1 is also not a big deal.

I hadn't seen these zone files, that would help as long as you limit the offsets to exact hours (I believe Afghanistan is a +4:30  during DST however) 

It's amazing how something as simple as time can be so damn complex :-)

-Jeff

Jeff Lange
Lead Software Engineer
GE Energy Services
Digital Energy

T +1 585 242 8375
F +1 585 241 5590
[email-masked]
www.GEDigitalEnergy.com

175 Science Parkway

GE imagination at work

---

From: Phil Shafer <[email-masked]>
Date: Fri, 22 Jun 2012 12:31:53 -0400

>> If someone configures lets say UTC offset +1, he likely wants exactly that and does no
>>t want any daylight savings time changes.

In the real world, this is not likely.  Folks want the real time zone
with the real local rules, however annoying those rules are.

>It's amazing how something as simple as time can be so damn complex :-)

Time is an _amazingly_ complex issue.  BSD has done a great job here
and makes the Gold Standard.  The zoneinfo files in /usr/share/zoneinfo/
describe 459 sets of time zone rules, covering not only current rules
but historical rules so files with pre-DST-changes timestamps are
displayed correctly.  Handles exotics like Sun Time and Indiana
Amazingly complex......

If you are making an offset, be sure to allow stuff like "EST5EDT".

FWIW:  The 459 number above is freebsd 8.2; macosx has 580 and BSD
head has even more.  Hurray!  JUNOS-11.4 lists 427, as well as naked
numbers and EST5EDT and other values supported by BSD.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Jun 2012 18:33:44 +0200

On Fri, Jun 22, 2012 at 03:41:41PM +0000, Lange, Jeffrey K (GE Energy) wrote:
> I can buy that, but perhaps there should be some description text stating that if the device supports automatic DST adjustment, setting the timezone via the utc-offset will prevent DST adjustments.  

This is what I assumed this means. If you have to manage devices in
many different time zones, you soon discover the value of absolute
timezone offsets so you can easily compare timestamps in logs without
having to ask the question whether in the time zones involved had DST
changes or not. Perhaps we need clarification that absolute offset
means absolute offset.

> Or even some way of configuring if you want the device to observe DST or not (perhaps that's just setting via the utc-offset).. and in that vein, should there be a config false or a feature that says if a device can even support DST?

Do the zones in the zone files not take care of this? Some are fixed,
some are moving, no?

> > And there are even zone files for GMT+1, GMT-1, ... hence setting a system's time to UTC +1 is also not a big deal.
> 

Yep. But then I would perhaps start thinking about how to generate the
proper zone file instead of having two mechanisms to support in my
code. I think for simple zones with fixed offsets, this is rather
simple (you create a one line zone definition and you compile it using
zic into a zone file).

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Jun 2012 18:43:27 +0200

> numbers and EST5EDT and other values supported by BSD.

I think the maintenance of the zones moved to IANA as described in RFC
6557. I am not sure BSD owns the credits of having the Gold Standard.
At the end, it is almost always a few individuals who do the work most
people use without every thinking about it. ;-)

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 23 Jun 2012 16:37:17 +0200 (CEST)

"Lange, Jeffrey K (GE Energy)" <[email-masked]> wrote:
> > > which means that if you have no way of automatically adjusting for
> > > daylight savings time.  Sure you could 'guess' the timezone based on the
> > > UTC offset, but that is hardly an exact method.
> >
> > If someone configures lets say UTC offset +1, he likely wants exactly that
> > and does not want any daylight savings time changes.
> 
> I can buy that, but perhaps there should be some description text stating that
> if the device supports automatic DST adjustment, setting the timezone via the
> utc-offset will prevent DST adjustments.

This is reasonable.  I think we should make this clarification.

> > I do not think you have to write lots of complicated code.

So... do you think that this is still an issue, or would the
clarification above be enough?

/martin

---

From: Phil Shafer <[email-masked]>
Date: Sat, 23 Jun 2012 18:53:21 -0400

>6557. I am not sure BSD owns the credits of having the Gold Standard.

Yup, BSD was just the place it first appeared, IIRC.  4.3BSD.

>people use without every thinking about it. ;-)

Yup, of course.  Arthur Olson and Paul Eggert did most of the the
ctime lib, but there is a wide/wild community that contributed
ideas, etc.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Sat, 23 Jun 2012 18:57:19 -0400

Juergen Schoenwaelder writes:
>If you have to manage devices in
>changes or not.

FWIW, this is not my experience.  Machines get set to the time zone
of the NOC (or person) that cares for them.  Sort of crazy, but true.

One of the benefits of syslog-ng is that we can ship timestamps as
structured data and let the host store/display them in whatever
time zone is desired.

Thanks,
 Phil

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Mon, 25 Jun 2012 11:55:02 +0000

> So... do you think that this is still an issue, or would the clarification above be enough?
>
>/martin

I think the textual clarification should be enough.

-Jeff

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Jun 2012 08:28:02 -0700

On Sat, Jun 23, 2012 at 7:37 AM, Martin Bjorklund <[email-masked]> wrote:

> that
Does this clarification mean the server MUST disable automatic DST
adjustment
if the timezone-utc-offset leaf exists?    That seems to be implied by
the YANG choice (timezone-location is deleted if timezone-utc-offset is
set.)
I will add a clarification in the description-stmt anyway.

Andy

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Tue, 26 Jun 2012 15:41:19 +0000

>Does this clarification mean the server MUST disable automatic DST adjustment
>the YANG choice (timezone-location is deleted if timezone-utc-offset is set.)

That is how I would interpret this.

-Jeff

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Tue, 26 Jun 2012 20:01:53 +0000

Not to beat a dead horse or anything but...  =)

The ietf-system module defines an enumeration for each of the timezone-name values.  Why is the timezone-location not also an enumeration?  I think this would greatly increase the usability as far as the end user is concerned.

I would propose that just like there is an iana-if-type model, there should be an iana-timezone model  seeing as the list is controlled by iana (http://www.iana.org/time-zones)

I would be willing to assemble this file if this is acceptable.

Thanks,
-Jeff

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Jun 2012 14:39:24 -0700

On Tue, Jun 26, 2012 at 1:01 PM, Lange, Jeffrey K (GE Energy) <
[email-masked]> wrote:

> The ietf-system module defines an enumeration for each of the
> timezone-name values.  Why is the timezone-location not also an
> enumeration?  I think this would greatly increase the usability as far as
> the end user is concerned.
>
>

timezone-name is being removed.
It has duplicates and is unusable for  an identifier.

> I would propose that just like there is an iana-if-type model, there
> should be an iana-timezone model  seeing as the list is controlled by iana (
> http://www.iana.org/time-zones)
>

OK with me.

Andy

---

From: t.petch <[email-masked]>
Date: Wed, 27 Jun 2012 12:00:00 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 26, 2012 4:28 PM
> > > > > daylight savings time.  Sure you could 'guess' the timezone
based on
> > the
> > > if the device supports automatic DST adjustment, setting the
timezone
> > via the

It is still not very user-riendly.

When I configure a Windows PC, probably the commonest device on the
planet, I have a drop-down which allows me to choose between GMT-12
through to GMT+12 wth a textual name for each which is not the same as
the string that you use.  The locale for this is UK, I cannot remember
what I got when last I configured a PC in North America, but think that
this is the sort of identifier that the real world uses.

And yes, there is also a tick box for
"Automatically adjust clock for daylight saving changes"
so this is what we should offer.

(My mobile phone does not adjust for daylight saving, I have to do it
manually).

Tom Petch

> > > > > get the current time when all the standard system APIs know
how to
> > use

------------------------------------------------------------------------
--------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jun 2012 14:00:44 +0200

> so this is what we should offer.

There is not DST regulation that applies to a fixed UTC offset. DST
regulations are country/region specific. Hence, selection GMT+x and
selecting adjust clock for daylight saving changes is only something
Windows knows how to do. ;-)

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 27 Jun 2012 12:20:54 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "t.petch" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, June 27, 2012 5:00 AM
> Subject: Re: [netmod] ietf-system: timezone-utc-offset
...
> Windows knows how to do. ;-)

Concrete example:  GMT -07 (Arizona) does not do DST while
GMT-07 (Mountain) does. Even "Arizona" is a bit of a misnomer;
for example the Navajo Nation within Arizona's borders uses
Mountain time rather than Arizona time.

Randy