Subject: [lmap] LMAP Information model: Calendar schedules and timezones

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Mon, 23 Jun 2014 21:38:40 +0000

Team,

I presented the calendar object to the BBF and suggested a timezone offset parameter as defined in LMAP Information model.

object {
[datetime ma-calendar-start;] // default: immediate
[datetime ma-calendar-end;] // default: indefinite
[int ma-calendar-months<0..*>;] // default: 1-12
[days ma-calendar-weekdays<0..*>;] // default: all
[int ma-calendar-hours<0..*>;] // default: 0-23
[int ma-calendar-minutes<0..*>;] // default: 0-59
[int ma-calendar-seconds<0..*>;] // default: 0-59
[int ma-calendar-timezone-offset;]
// default: system timezone offset
} ma-calendar-obj;

What the BBHome group noted was that the datetime object type already has a timezone element associated with the type.

So the suggestion is that that the schedule should utilize the timezone of the start and end time parameters and that we constrain these parameters to use the same timezone. This should solve the problem without the need for a timezone offset parameter.

Thoughts?

Thanks,
Tim

---

From: Brian Trammell <[email-masked]>
Date: Mon, 23 Jun 2014 23:40:51 +0200

hi, Tim, all,

Is there any reason not to simply mandate the use of UTC here?

Cheers,

Brian

On 23 Jun 2014, at 23:38, Carey, Timothy (Timothy) <[email-masked]> wrote:

> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Mon, 23 Jun 2014 22:18:17 +0000

Brian,

There was a request for a time to be used as the local timezone of host - when a timezone is not supplied.

Calendar Timing is also required to perform measurements at
meaningful instances in relation to network usage (e.g., at peak
times). If the optional timezone offset is not supplied then local
system time is assumed. This is essential in some use cases to
ensure consistent peak-time measurements as well as supporting MA
devices that may be in an unknown timezone or roam between different
timezones (but know their own timezone information such as through
the mobile network).

So an ISO 8601 dateTime already has a timezone - so we should use these if provided and we should constrain the start and end to use the same time zone.

Unfortunately I think the ISO 8601 datetime states that an undocumented timezone is undetermined. This is what the BBF uses for a data type.

We could just state that an undocumented timezone is default timezone of the system - that should work as well.

BR,
Tim

From: Brian Trammell [mailto:[email-masked]]
Sent: Monday, June 23, 2014 3:41 PM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [lmap] LMAP Information model: Calendar schedules and timezones

hi, Tim, all,

Cheers,

Brian

On 23 Jun 2014, at 23:38, Carey, Timothy (Timothy) <[email-masked]<mailto:[email-masked]>> wrote:

Team,

object {

Thoughts?

Thanks,
Tim
_______________________________________________
lmap mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lmap

---

From: Brian Trammell <[email-masked]>
Date: Tue, 24 Jun 2014 08:33:25 +0200

On 24 Jun 2014, at 00:18, Carey, Timothy (Timothy) <[email-masked]> wrote:

> Brian,
>  
> There was a request for a time to be used as the local timezone of host – when a timezone is not supplied.

In my experience, this works really well in single-timezone operations (e.g. most small-country national operators), less well but still managably in multiple-timezone operations (e.g. US national-level), and is a source of a whole lot of headache in global operations. But I suppose most operations with this problem have already learned to stop making these mistakes.

> So an ISO 8601 dateTime already has a timezone – so we should use these if provided and we should constrain the start and end to use the same time zone.

ISO8601, IIRC, states timezones in absolute offset to UTC. So this would introduce the corner case that a calendar that starts on one side of a DST transition must continue using the pre-transition timezone, even when the system time changes out from underneath the LMAP application(s).

> We could just state that an undocumented timezone is default timezone of the system – that should work as well.

Basing all this on 8601 does give operators the _choice_ to use local timezone if they wish... but I do think we should warn implementors/operator users about (1) the corner cases (DST) and (2) issues with management/assumptions when controller/MA connections (or MA/collector connections, but that's a reporting protocol issue) cross TZ boundaries.

That's a guideline in a different document. Alternately, we could state  in the information model that TZ MUST be explicit.

Cheers,

Brian

---

From: <[email-masked]>
Date: Tue, 24 Jun 2014 15:01:59 +0100

Hi Brian

UTC is mandatory in the information model wherever we have a time/date. However, in expressing the list of hours in which the measurement is to run we also need to express an offset to provide the same functionality. In this way we can say, for example, to run the test during the hours 18, 19, 20, 21 and 22 local time to measure 'peak' performance.

Trevor.

From: lmap [mailto:[email-masked]] On Behalf Of Brian Trammell
Sent: 23 June 2014 22:41
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [lmap] LMAP Information model: Calendar schedules and timezones

hi, Tim, all,

Cheers,

Brian

Team,

object {

Thoughts?

Thanks,
Tim

---

From: Brian Trammell <[email-masked]>
Date: Tue, 24 Jun 2014 16:05:00 +0200

hi Trevor,

Okay, got it. There should still be documentation of corner cases (though in your "peak hour" use case, you generally won't be running the test through a DST transition :) ), and a note for implementors (though probably not in the information model) that this is something that's quite easy to get wrong in a confusing way.

Cheers,

Brian

On 24 Jun 2014, at 16:01, <[email-masked]> <[email-masked]> wrote:

> Hi Brian
>  
> UTC is mandatory in the information model wherever we have a time/date. However, in expressing the list of hours in which the measurement is to run we also need to express an offset to provide the same functionality. In this way we can say, for example, to run the test during the hours 18, 19, 20, 21 and 22 local time to measure ‘peak’ performance.
>  
> Trevor.
>  
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Jun 2014 12:44:33 +0200

> We could just state that an undocumented timezone is default timezone of the system - that should work as well.

Just for clarity, I think what we want to use is RFC 3339, which
defines the "Internet Date/Time Format", which is essentially ISO 8601
but with a few important simplifications.

/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: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Thu, 26 Jun 2014 12:36:13 +0000

Juergen,

We can do that but we will have to define a new data type for date time than the one used by BBF which is the standard xs:datetime from SOAP (ISO 8601).
I saw in the information model  that it indeed does reference RFC3339.

So then would we say a datetime without a timestamp is UTC and datetime with -00:00 is system local and we use the starttime for the timezone of the schedule (which isn't datetime)?

A TR-069 device already has has a system local timezone - so for BBF we will not need an additional parameter as part of the schedule - since it is already part of the device.

What do you think?

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, June 26, 2014 4:45 AM
To: Carey, Timothy (Timothy)
Cc: Brian Trammell; [email-masked]
Subject: Re: [lmap] LMAP Information model: Calendar schedules and timezones

> We could just state that an undocumented timezone is default timezone of the system - that should work as well.

Just for clarity, I think what we want to use is RFC 3339, which defines the "Internet Date/Time Format", which is essentially ISO 8601 but with a few important simplifications.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Jun 2014 14:55:30 +0200

On Thu, Jun 26, 2014 at 12:36:13PM +0000, Carey, Timothy (Timothy) wrote:
> 
> So then would we say a datetime without a timestamp is UTC and
> datetime with -00:00 is system local and we use the starttime for
> the timezone of the schedule (which isn't datetime)?

Not sure what you mean with "timestamp". Let me assume you mean
'time-offset'. Then yes, my understanding is that you would use -00:00
if the timezone offset is unknown and things are interpreted to the
notion of time local on the system.

BTW, the definition of data-and-time in RFC 6021 summarizes how I
understand the difference between XSDs dateTime type and RFC 3339.
(And I think XSDs dateTime is again a profile of the ISO 8601
definition.)

/js

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Thu, 26 Jun 2014 13:02:26 +0000

Yes that is what I meant; I will take a look at RFC 6021; thanks.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, June 26, 2014 6:56 AM
To: Carey, Timothy (Timothy)
Cc: Brian Trammell; [email-masked]
Subject: Re: [lmap] LMAP Information model: Calendar schedules and timezones

On Thu, Jun 26, 2014 at 12:36:13PM +0000, Carey, Timothy (Timothy) wrote:
> datetime with -00:00 is system local and we use the starttime for the 
> timezone of the schedule (which isn't datetime)?

Not sure what you mean with "timestamp". Let me assume you mean 'time-offset'. Then yes, my understanding is that you would use -00:00 if the timezone offset is unknown and things are interpreted to the notion of time local on the system.

BTW, the definition of data-and-time in RFC 6021 summarizes how I understand the difference between XSDs dateTime type and RFC 3339.
(And I think XSDs dateTime is again a profile of the ISO 8601
definition.)

/js