Subject: Re: [CDNi] Trigger time policy using local time

From: Ori Finkelman <[email-masked]>
Date: Mon, 12 Nov 2018 14:51:58 +0200

Hi,
In the CDNI meeting we have discussed how to represent local time at the
trigger destination where there are multiple destination locations in
different time zones.

Two options raised:
*1. Follow RFC 3339, and add a new notion for "your local time" *
For example: 2018-11-12T02:30:00.00L
should be interpreted as November 12th, 2018, 2:30AM at your own local time.

*2. Use UTC / UNIX epoch with a local time flag.*
For example: 1541989800 For and {"local-time": true} means
2018-11-12T02:30:00.00
but servers MUST interpret that in their own local time.
I.e. servers MUST reduce their time offset from the UNIX epoch before
interpreting the time.
For example, a server located at UTC+02:00 must reduce 7200 seconds from
this eopch, resulting in 1541982600 which is 2018-11-12T02:30:00.00+02:00
If a sever is located at UTC-04:00 it must reduce -14,400 seconds epoch,
resulting in 1542004200 which is 2018-11-12T02:30:00.00-04:00

Personally I am in favor of option 2, as option 1 will require changes in
time parser and is probably best done by an updated RFC on top of RFC 3339,
not sure this use case justifies it.
I will also ping the authors of RFC3339 to get their views, but would
appreciate any input at the mean time.

Thanks,
Ori

On Mon, Oct 15, 2018 at 12:23 PM Ori Finkelman <[email-masked]> wrote:

> Hi,
> In the last CDNI meeting we have agreed to add to the time policy the
> local-time flag (see below).
> The required semantics is the instruct the dCDN to run the trigger at the
> given time window in there own local time.
> For example: "I want you to run this trigger between 3AM-5AM at your own
> local time".
>
> The reasoning is that network resource availability and prices may vary
> across the day, and specifically are more available and less expensive at
> off-peak hours. however off-peak hours are local per region.
> In the past we have proposed to avoid adding this flag by using a
> combination of location policy and time policy, but that would require
> calling a separate trigger for each region.
>
> While working on adding this "local-time" flag, I have realized that
> TimeWindow as defined in
> https://tools.ietf.org/html/rfc8006#section-4.2.3.2 in UTC and it is
> better not be used to represent local time.
> The only option I can think of using textual time format as defined in
> RFC3339, and the local time flag should be interpreted by the dCDN as "you
> should interpret this as if it in your own local time".
> Using RFC3339 means we need to add a new time object instead of the
> TimeWindow.
>
> Thoughts ?
>
> Thanks,
> Ori
>
>
> On Sun, Jul 22, 2018 at 9:19 AM Ori Finkelman <[email-masked]> wrote:
>
>> Here are the comments we got CDNI meeting.
>>
>> *Playlist:*
>> change abr-protocol to media-protocol, as it may be used for other media
>> rather than video abr.
>>
>> *Trigger TimePolicy:*
>> Add local-time flag. When true the trigger should be executed at the
>> local time, per zone.
>>
>> *Trigger error and warning propagation:*
>> Considering triggers may be propagated to a chain of dCDNs, and
>> considering we allow extensions to be safe-to-redistribute even if not
>> understood, we should add a mechanism for propagating errors and warnings
>> back to the uCDN.
>>
>> Thanks,
>> Ori
>>
>> --
>>
>> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
>> [email-masked]
>>
>
>
> --
>
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
> [email-masked]
>

-- 

*Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
[email-masked]

---

From: Phil Sorber <[email-masked]>
Date: Mon, 12 Nov 2018 13:14:48 -0700

What about section 4.3 of RFC3339?

https://tools.ietf.org/html/rfc3339#section-4.3

using the -0000 offset to signify local time.

Also, it seems that ISO8601 also has a "local time" where you just don't
include an offset:

https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators

"If no UTC relation information is given with a time representation, the
time is assumed to be in local time."

Also in RFC 2822 section 3.3 (
https://tools.ietf.org/html/rfc2822#section-3.3):

"Though "-0000" also indicates Universal Time, it is used to indicate that
the time was generated on a system that may be in a local time zone other
than Universal Time and therefore indicates that the date-time contains no
information about the local time zone."

On Mon, Nov 12, 2018 at 5:53 AM Ori Finkelman <[email-masked]> wrote:

> For example: 1541989800 For and {"local-time": true} means 2018-11-12T02:30:00.00
>>> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <+972%2072-222-1647> |
>>> Mobile: +972-52-3832189 <+972%2052-383-2189> | [email-masked]
>>>
>>
>>
>> --
>>
>> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <+972%2072-222-1647> |
>> Mobile: +972-52-3832189 <+972%2052-383-2189> | [email-masked]
>>
>
>
> --
>
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <+972%2072-222-1647> |
> Mobile: +972-52-3832189 <+972%2052-383-2189> | [email-masked]
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>

---

From: Ori Finkelman <[email-masked]>
Date: Mon, 12 Nov 2018 22:41:23 +0200

Hi Phil,
Though it may seem so, this is not our case and using it may create
confusion.
What we need is something that executes in different absolute times in
different locations.

>> This means that the time is actually in UTC (same as +0000) but the time
zone was not supposed to be 0, it is just unknown, and is therefore using 0.

include an offset:
>> This actually means that time is in the local time of the caller, which
means that if you translate it to UTC you should get the caller time + the
correct offset. This is a specific absolute time, not something that can be
interpreted as different UTC in different time zones.
We can decide that when we say "local time" we actually mean the receivers
local time rather than the callers local time, but then again, if for
example the trigger server is located at NY, then 4AM will mean 4AM in
local time in NY (i.e. +0500). Using it to designate 4AM depending on where
the cache is found is non-standard.
I was rather hoping we can have something which designate exactly what we
mean, but I guess that passing the time with no time-zone and adding a flag
that says "use in your own local time" may be do it. But in this case, I
would take Chris proposal and use UNIX epoch as it is easier to parse and
is already been used in CDNI.

Thanks,
Ori

On Mon, Nov 12, 2018 at 10:15 PM Phil Sorber <[email-masked]> wrote:

>> This means that the time is actually in UTC (same as +0000) but the time
zone was not supposed to be 0, it is just unknown, and is therefore using 0.

>> This actually means that time is in the local time of the caller, which
means that if you translate it to UTC you should get the caller time + the
correct offset. This is a specific absolute time, not something that can be
interpreted as different UTC in different time zones.

>> This is the same as the above, We can decide that when we say "local
time" we actually mean the receivers local time rather than the callers
local time, but then again, if for example the trigger server is located at
NY, then the 4AM will mean local time in NY. Using it to designate 4AM
depending on where the cache is found is non-standard.

>>> The required semantics is the instruct the dCDN to run the trigger at
>>> the given time window in there own local time.
>>>> change abr-protocol to media-protocol, as it may be used for other
>>>> media rather than video abr.
>>>>
>>>> *Trigger TimePolicy:*

--

---

From: Chris Lemmons <[email-masked]>
Date: Mon, 12 Nov 2018 15:46:28 -0700

Part of the issue with ISO 8601 is that it is a bit annoying to parse.
It allows you to leave out all sorts of things and really defines a
whole bunch of formats. All these formats are "ISO8601":
2018-11-12T17:38:41+00:00
2018-W46
2018-W46-1
--11-12
2018-316

And a whole bunch of others. Obviously, most of those leave out some
information that ought to be required. But actually implementing a
full parser for it is a bit tougher than for some other formats.

Consider something like "local-offset: true", to indicate that a local
offset should be added to the UTC time specified. This achieves the
effect of executing it in the local time zone.
On Mon, Nov 12, 2018 at 1:42 PM Ori Finkelman <[email-masked]> wrote:
>
> Hi Phil,
> Though it may seem so, this is not our case and using it may create confusion.
> What we need is something that executes in different absolute times in different locations.
>
> >> This means that the time is actually in UTC (same as +0000) but the time zone was not supposed to be 0, it is just unknown, and is therefore using 0.
>
> Also, it seems that ISO8601 also has a "local time" where you just don't include an offset:
> >> This actually means that time is in the local time of the caller, which means that if you translate it to UTC you should get the caller time + the correct offset. This is a specific absolute time, not something that can be interpreted as different UTC in different time zones.
> We can decide that when we say "local time" we actually mean the receivers local time rather than the callers local time, but then again, if for example the trigger server is located at NY, then 4AM will mean 4AM in local time in NY (i.e. +0500). Using it to designate 4AM depending on where the cache is found is non-standard.
> I was rather hoping we can have something which designate exactly what we mean, but I guess that passing the time with no time-zone and adding a flag that says "use in your own local time" may be do it. But in this case, I would take Chris proposal and use UNIX epoch as it is easier to parse and is already been used in CDNI.
>
> Thanks,
> Ori
>
>
>
>
>
>
>
> >> This means that the time is actually in UTC (same as +0000) but the time zone was not supposed to be 0, it is just unknown, and is therefore using 0.
>>
>>
>> Also, it seems that ISO8601 also has a "local time" where you just don't include an offset:
>
> >> This actually means that time is in the local time of the caller, which means that if you translate it to UTC you should get the caller time + the correct offset. This is a specific absolute time, not something that can be interpreted as different UTC in different time zones.
>>
>>
>> "If no UTC relation information is given with a time representation, the time is assumed to be in local time."
>
>
> >> This is the same as the above, We can decide that when we say "local time" we actually mean the receivers local time rather than the callers local time, but then again, if for example the trigger server is located at NY, then the 4AM will mean local time in NY. Using it to designate 4AM depending on where the cache is found is non-standard.
>
>
>
>
>>
>>
>> Also in RFC 2822 section 3.3 (https://tools.ietf.org/html/rfc2822#section-3.3):
>>
>> "Though "-0000" also indicates Universal Time, it is used to indicate that the time was generated on a system that may be in a local time zone other than Universal Time and therefore indicates that the date-time contains no information about the local time zone."
>>
>>> In the CDNI meeting we have discussed how to represent local time at the trigger destination where there are multiple destination locations in different time zones.
>>>
>>> Two options raised:
>>> 1. Follow RFC 3339, and add a new notion for "your local time"
>>> 2. Use UTC / UNIX epoch with a local time flag.
>>> For example: 1541989800 For and {"local-time": true} means 2018-11-12T02:30:00.00 but servers MUST interpret that in their own local time.
>>> I.e. servers MUST reduce their time offset from the UNIX epoch before interpreting the time.
>>> For example, a server located at UTC+02:00 must reduce 7200 seconds from this eopch, resulting in 1541982600 which is 2018-11-12T02:30:00.00+02:00
>>> If a sever is located at UTC-04:00 it must reduce -14,400 seconds epoch, resulting in 1542004200 which is 2018-11-12T02:30:00.00-04:00
>>>
>>> Personally I am in favor of option 2, as option 1 will require changes in time parser and is probably best done by an updated RFC on top of RFC 3339, not sure this use case justifies it.
>>> I will also ping the authors of RFC3339 to get their views, but would appreciate any input at the mean time.
>>>
>>> Thanks,
>>> Ori
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> In the last CDNI meeting we have agreed to add to the time policy the local-time flag (see below).
>>>> The required semantics is the instruct the dCDN to run the trigger at the given time window in there own local time.
>>>> For example: "I want you to run this trigger between 3AM-5AM at your own local time".
>>>>
>>>> The reasoning is that network resource availability and prices may vary across the day, and specifically are more available and less expensive at off-peak hours. however off-peak hours are local per region.
>>>> In the past we have proposed to avoid adding this flag by using a combination of location policy and time policy, but that would require calling a separate trigger for each region.
>>>>
>>>> While working on adding this "local-time" flag, I have realized that TimeWindow as defined in https://tools.ietf.org/html/rfc8006#section-4.2.3.2 in UTC and it is better not be used to represent local time.
>>>> The only option I can think of using textual time format as defined in RFC3339, and the local time flag should be interpreted by the dCDN as "you should interpret this as if it in your own local time".
>>>> Using RFC3339 means we need to add a new time object instead of the TimeWindow.
>>>>
>>>> Thoughts ?
>>>>
>>>> Thanks,
>>>> Ori
>>>>
>>>>
>>>>> Playlist:
>>>>> change abr-protocol to media-protocol, as it may be used for other media rather than video abr.
>>>>>
>>>>> Trigger TimePolicy:
>>>>> Add local-time flag. When true the trigger should be executed at the local time, per zone.
>>>>>
>>>>> Trigger error and warning propagation:
>>>>> Considering triggers may be propagated to a chain of dCDNs, and considering we allow extensions to be safe-to-redistribute even if not understood, we should add a mechanism for propagating errors and warnings back to the uCDN.
>>>>>
>>>>> Thanks,
>>>>> Ori
>>>>>
>>>>> --
>>>>> Ori Finkelman
>>>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | [email-masked]
>>>>
>>>>
>>>>
>>>> --
>>>> Ori Finkelman
>>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | [email-masked]
>>>
>>>
>>>
>>> --
>>> Ori Finkelman
>>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | [email-masked]
> Ori Finkelman
> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | [email-masked]

---

From: Ori Finkelman <[email-masked]>
Date: Tue, 13 Nov 2018 09:53:09 +0200

Hi Chris,
I might be missing your exact intention, but I think that the dCDN need to
reduce their local offset, in each location, rather than adding it.
For example:
Suppose you want a trigger to run at 02:30 AM, local time, in each and
every location, so you communicate that as 02:30AM in UTC time  and set the
local-offset to true.
Now, if you are located, like me, in Israel and your local offset
is +02:00, and you want it to be executed at 02:30AM in Israel, you need to
reduce 2 hours from the UTC epoch so that
the resulting epoch would be at 02:30AM IL time.
OTOH, if you are located in Denver and your offset is -07:00, and you want
the trigger to run at 02:30AM Denver time, you need to reduce -07:00 (add 7
hours) to get the correct epoch.

Thanks,
Ori

On Tue, Nov 13, 2018 at 12:46 AM Chris Lemmons <[email-masked]> wrote:

> > >> This means that the time is actually in UTC (same as +0000) but the
> time zone was not supposed to be 0, it is just unknown, and is therefore
> using 0.
> >
> > >> This actually means that time is in the local time of the caller,
> which means that if you translate it to UTC you should get the caller time
> + the correct offset. This is a specific absolute time, not something that
> can be interpreted as different UTC in different time zones.
> > We can decide that when we say "local time" we actually mean the
> receivers local time rather than the callers local time, but then again, if
> for example the trigger server is located at NY, then 4AM will mean 4AM in
> > I was rather hoping we can have something which designate exactly what
> we mean, but I guess that passing the time with no time-zone and adding a
> flag that says "use in your own local time" may be do it. But in this case,
> I would take Chris proposal and use UNIX epoch as it is easier to parse and
> > >> This means that the time is actually in UTC (same as +0000) but the
> time zone was not supposed to be 0, it is just unknown, and is therefore
> using 0.
> >>
> >>
> > >> This actually means that time is in the local time of the caller,
> which means that if you translate it to UTC you should get the caller time
> + the correct offset. This is a specific absolute time, not something that
> can be interpreted as different UTC in different time zones.
> >>
> >>
> >> "If no UTC relation information is given with a time representation,
> the time is assumed to be in local time."
> >
> >
> >> "Though "-0000" also indicates Universal Time, it is used to indicate
> that the time was generated on a system that may be in a local time zone
> other than Universal Time and therefore indicates that the date-time
> contains no information about the local time zone."
> >>
> >>> In the CDNI meeting we have discussed how to represent local time at
> the trigger destination where there are multiple destination locations in
> different time zones.
> >>>
> >>> Two options raised:
> 2018-11-12T02:30:00.00 but servers MUST interpret that in their own local
> time.
> >>> For example, a server located at UTC+02:00 must reduce 7200 seconds
> from this eopch, resulting in 1541982600 which is
> 2018-11-12T02:30:00.00+02:00
> >>> If a sever is located at UTC-04:00 it must reduce -14,400 seconds
> epoch, resulting in 1542004200 which is 2018-11-12T02:30:00.00-04:00
> >>>
> >>> Personally I am in favor of option 2, as option 1 will require changes
> in time parser and is probably best done by an updated RFC on top of RFC
> 3339, not sure this use case justifies it.
> >>>> The reasoning is that network resource availability and prices may
> vary across the day, and specifically are more available and less expensive
> at off-peak hours. however off-peak hours are local per region.
> >>>> The only option I can think of using textual time format as defined
> in RFC3339, and the local time flag should be interpreted by the dCDN as
> "you should interpret this as if it in your own local time".

--

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 13 Nov 2018 14:53:59 +0000

Hi,

> full parser for it is a bit tougher than for some other formats.

I agree that generic ISO 8601 format is not what you want, that is why RFC 3339 was defined in the first place. RFC 3339 defines a subset which is much easier to parse.

You could have a look at ISO 8601 and see how "local timezone" is defined there and just extend RFC 3339 for this case, without adding support for all other optional things in ISO 8601.

Just my 2p.

---

From: Ori Finkelman <[email-masked]>
Date: Wed, 14 Nov 2018 11:02:20 +0200

Thanks Alexey,
I will look into it.

Ori

On Tue, Nov 13, 2018 at 4:54 PM Alexey Melnikov <[email-masked]>
wrote:

> I agree that generic ISO 8601 format is not what you want, that is why RFC
> 3339 was defined in the first place. RFC 3339 defines a subset which is
> much easier to parse.
>
> You could have a look at ISO 8601 and see how "local timezone" is defined
> there and just extend RFC 3339 for this case, without adding support for
> all other optional things in ISO 8601.
>
> Just my 2p.
>
> > > >> This is the same as the above, We can decide that when we say
> "local time" we actually mean the receivers local time rather than the
> callers local time, but then again, if for example the trigger server is
> located at NY, then the 4AM will mean local time in NY. Using it to
> designate 4AM depending on where the cache is found is non-standard.
> > >
> > >
> > >
> > >
> > >>
> > >>
> > >>> Personally I am in favor of option 2, as option 1 will require
> changes in time parser and is probably best done by an updated RFC on top
> of RFC 3339, not sure this use case justifies it.
> > >>> I will also ping the authors of RFC3339 to get their views, but
> would appreciate any input at the mean time.
> > >>>
> > >>> Thanks,
> > >>> Ori
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>> The required semantics is the instruct the dCDN to run the trigger
> at the given time window in there own local time.
> > >>>> While working on adding this "local-time" flag, I have realized
> that TimeWindow as defined in

--

---

From: Ori Finkelman <[email-masked]>
Date: Thu, 15 Nov 2018 14:56:02 +0200

Hi,
Looking at ISO8601, local time is simply defined by not adding the offset
(or Z).
For example: 2018-11-12T02:30:00.00
Is interpreted as 2:30AM at the local time.

RFC 3339 does not support this option as the RFC is focused on
interoperability, and when what you want is to have a deterministic way to
establish an agreement on a specific absolute time, you can either use UTC
or local time with an offset from UTC.

We can adopt that option for our use case as it is not trying to agree on
an absolute time but rather on the local.

Is this an acceptable solution?

If so, how do we standardize it ? as a CDNI time, or as an extension to RFC
3339 ?

Thanks,
Ori

On Wed, Nov 14, 2018 at 11:02 AM Ori Finkelman <[email-masked]> wrote:

>> I agree that generic ISO 8601 format is not what you want, that is why
>> RFC 3339 was defined in the first place. RFC 3339 defines a subset which is
>> much easier to parse.
>>
>> > > >> This means that the time is actually in UTC (same as +0000) but
>> the time zone was not supposed to be 0, it is just unknown, and is
>> therefore using 0.
>> > >
>> > > I was rather hoping we can have something which designate exactly
>> what we mean, but I guess that passing the time with no time-zone and
>> adding a flag that says "use in your own local time" may be do it. But in
>> this case, I would take Chris proposal and use UNIX epoch as it is easier
>> to parse and is already been used in CDNI.
>> > >
>> > > Thanks,
>> > > Ori
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > >> This means that the time is actually in UTC (same as +0000) but
>> the time zone was not supposed to be 0, it is just unknown, and is
>> therefore using 0.
>> > >>
>> > >>
>> > >> "Though "-0000" also indicates Universal Time, it is used to
>> indicate that the time was generated on a system that may be in a local
>> time zone other than Universal Time and therefore indicates that the
>> date-time contains no information about the local time zone."
>> > >>
>> > >>> In the CDNI meeting we have discussed how to represent local time
>> at the trigger destination where there are multiple destination locations
>> in different time zones.
>> > >>>
>> > >>> Two options raised:
>> > >>>> The only option I can think of using textual time format as
>> defined in RFC3339, and the local time flag should be interpreted by the
>> dCDN as "you should interpret this as if it in your own local time".

--

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Thu, 15 Nov 2018 15:29:07 +0100

> On Nov 15, 2018, at 13:56, Ori Finkelman <[email-masked]> wrote:
> 
> We can adopt that option for our use case as it is not trying to agree on an absolute time but rather on the local.

For a CDN what does local time mean?

What’s the use case for this? (Apologies if it was clarified earlier, but it doesn’t make sense to me).

Ask

---

From: Ori Finkelman <[email-masked]>
Date: Thu, 15 Nov 2018 17:34:55 +0200

Hi,
CDNI Triggers interface is a special case,
Let's take CDN-A and CDN-B, both have presence in multiple regions, but
they don't share the same coverage, so CDN-A (upstream CDN) uses CDN-B
(downstream CDN) in order to extend its coverage.

Now CDN-A needs to pre-position some content on its caches, and it wishes
CDN-B to pull the content to its caches as well.
CDN-A wants CDN-B to pull the content to the caches from CDN-A at off peak
hours, for example 2AM-4AM.
However, since both are located in multiple regions, the off peak time
depends on each specific region. There is no single absolute time which is
right for all timezones.

What we are looking for is to extend the trigger interface such that one
can define the time in which the trigger should be executed, but in this
case the time depends on the on the geography.

Our proposal is to have an interface to tell the dCDN "I want you to
execute the trigger at a specific time in your local times as they are per
region".

Hope this explains the context.

Thanks,
Ori

On Thu, Nov 15, 2018 at 4:29 PM Ask Bjørn Hansen <[email-masked]> wrote:

> > We can adopt that option for our use case as it is not trying to agree
> on an absolute time but rather on the local.
>

--

---

From: Ori Finkelman <[email-masked]>
Date: Sun, 18 Nov 2018 11:28:47 +0200

Hi Ask,
Would love to know if my explanation make sense. If there are other
alternatives we haven't though about that could satisfy the trigger
scheduling requirements, i'd be happy to check them out.

All, here is my proposal for the time window object that is using internet
timestamp (as RFC3339) instead of UNIX epoch.
As proposed by Alexey and others, I have followed ISO8601 that defines a
time without an offset to be the local time.
I'm currently defining a new object rather than extending and versioning
the TimeWindow defined in section 4.2.3.2 of RFC8006
<https://tools.ietf.org/html/rfc8006#section-4.2.3.2>, the reason is that
the object is too simple, I think it would be wrong to version it.

TimestampWindow

   A TimestampWindow object describes a time range that can be applied by a
   TimePolicy, e.g., start 2000-01-01T02:30:00.00Z, end:
2000-01-01T04:30:00.00Z.

      Property: start

         Description: The start time of the window.

         Type: Timestamp (see *Timestamp *below)

         Mandatory-to-Specify: Yes.

      Property: end

         Description: The end time of the window.

         Type: Timestamp (see *Timestamp *below)

         Mandatory-to-Specify: Yes.

   Example TimestampWindow object that describes a time window from 02:30
   01/01/2000 UTC to 04:30 01/01/2000 UTC:

   {
     "start": 2000-01-01T02:30:00.00Z,
     "end": 2000-01-01T04:30:00.00Z,
   }

Timestamp

   A timestamp value expressed as Internet time as defined by section
5.6 of [RFC3339] <https://tools.ietf.org/html/rfc3339#section-5.6>,
with the following extension:

   A timestamp (date and time string) MAY be used without the
time-numoffset or time-offset elements, in which case the reader

   must interpret it as their own local time.

   Type: A non-empty JSON string where the string is an Internet
timestamp as defined in [RFC3339] with the modification

   for local time as explained above.

   Example 1 time representing 09:00:00 01/01/2000 UTC:
   2000-01-01T09:00:00.00Z

   Example 2 time representing 09:00:00 01/01/2000 at the reader's local time:
   2000-01-01T09:00:00.00

   Example 3 time representing 09:00:00 01/01/2000 local time at offset -05:00:
   2000-01-01T09:00:00.00-05:00

Thanks,

Ori

--

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 18 Nov 2018 13:18:08 +0000

Hi,

> On 15 Nov 2018, at 12:56, Ori Finkelman <[email-masked]> wrote:
> 
> Hi,
> Looking at ISO8601, local time is simply defined by not adding the offset (or Z).
> RFC 3339 does not support this option as the RFC is focused on interoperability, and when what you want is to have a deterministic way to establish an agreement on a specific absolute time, you can either use UTC or local time with an offset from UTC.
> 
> If so, how do we standardize it ? as a CDNI time, or as an extension to RFC 3339 ?

Just include in your document. You can cut & paste ABNF from RFC 3339 and modify as needed.
>>> On Tue, Nov 13, 2018 at 4:54 PM Alexey Melnikov <[email-masked]> wrote:
>>> Hi,
>>>

---

From: Ori Finkelman <[email-masked]>
Date: Sun, 18 Nov 2018 15:32:34 +0200

Thanks, I will do that.
Best regards,
Ori

On Sun, Nov 18, 2018 at 3:18 PM Alexey Melnikov <[email-masked]>
wrote:

>>> You could have a look at ISO 8601 and see how "local timezone" is
>>> defined there and just extend RFC 3339 for this case, without adding
>>> support for all other optional things in ISO 8601.
>>>
>>> Just my 2p.
>>>
>>> > >> "If no UTC relation information is given with a time
>>> representation, the time is assumed to be in local time."
>>> > >
>>> > >
>>> > >>> For example, a server located at UTC+02:00 must reduce 7200
>>> seconds from this eopch, resulting in 1541982600 which is
>>> > >>>> The required semantics is the instruct the dCDN to run the
>>> trigger at the given time window in there own local time.
>>> > >>>> The reasoning is that network resource availability and prices
>>> may vary across the day, and specifically are more available and less
>>> expensive at off-peak hours. however off-peak hours are local per region.

--

---

From: Ori Finkelman <[email-masked]>
Date: Sun, 25 Nov 2018 10:13:19 +0200

Got feedback from Chris Newman, the author of RFC3339. This RFC does not
have support for non-coordinated local time intentionally, as the purpose
of this RFC was to created a timestamp which is interoperable, so that
different systems will interpret it as the same UTC,
Therefore, we cannot use RFC3339 timestamp as the base for this use case,
as we want to allow exactly that.
I will therefore follow Alexey's suggestion and redefine the format in the
triggers extension I-D, so that it suits this purpose.

Ori

On Sun, Nov 18, 2018 at 3:32 PM Ori Finkelman <[email-masked]> wrote:

>>>> > > >> This actually means that time is in the local time of the
>>>> caller, which means that if you translate it to UTC you should get the
>>>> caller time + the correct offset. This is a specific absolute time, not
>>>> something that can be interpreted as different UTC in different time zones.
>>>> > > >> This actually means that time is in the local time of the
>>>> caller, which means that if you translate it to UTC you should get the
>>>> caller time + the correct offset. This is a specific absolute time, not
>>>> something that can be interpreted as different UTC in different time zones.
>>>> > >>
>>>> > >>
>>>> > >>>> In the past we have proposed to avoid adding this flag by using
>>>> a combination of location policy and time policy, but that would require
>>> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189
>>> | [email-masked]
>>>
>>
>>
>> --
>>

--