Hi Dulitha,
On Fri, Jun 24, 2016 at 8:11 PM, Dulitha Wijewantha
wrote:
> Hi Inosh,
> If epoach time is received to the server I don't understand the
> limitation? Is it because Siddhi time window doesn't operate in UTC time?
>
As I explained above, using received timestamp we
Hi Inosh,
If epoach time is received to the server I don't understand the limitation?
Is it because Siddhi time window doesn't operate in UTC time?
Cheers~
On Tue, Jun 14, 2016 at 7:00 AM, Inosh Goonewardena wrote:
> Hi Sajith,
>
>
> On Tue, Jun 14, 2016 at 12:21 PM, Sajith
Hi Inosh,
In order to do this we might probably need to update the data publishers to
send their time zones as meta data to do the time zone conversion.
In cases like daylight saving changes this information will be required to
correctly map the incoming time to UTC
Also, isn't it an option
Hi Ruwan,
On Mon, Jun 13, 2016 at 7:13 PM, Ruwan Abeykoon wrote:
> Hi All,
> +1 on storing time in UTC.
>
> However this will cause some minor (but annoying) discrepancies to occur
> when we do windowing on "per-hour" basis, when the time zone difference
> between UTC and the
+1, yes... We can extend Siddhi Time functions to allow timezone as a
parameter.. Will do that..
On Mon, Jun 13, 2016 at 7:13 PM, Ruwan Abeykoon wrote:
> Hi All,
> +1 on storing time in UTC.
>
> However this will cause some minor (but annoying) discrepancies to occur
> when
Hi All,
+1 on storing time in UTC.
However this will cause some minor (but annoying) discrepancies to occur
when we do windowing on "per-hour" basis, when the time zone difference
between UTC and the server is not full hour. e.g. +5:30 UTC.
Is there any solution for that?
Cheers,
Ruwan
On Mon,
Hi,
In analytics use cases we use a couple of extensions to extract attributes
(year, month, day, hour, etc.) from the event timestamp. In product
anaytics implementations, we mostly use time:extract() Siddhi extension [1]
in real time scenarios and DateTimeUDF in batch scenarios [2]. However,