You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oozie.apache.org by John Armstrong <jo...@ccri.com> on 2011/08/30 20:49:16 UTC
Adjusting for time zone in coordinator EL
I'm trying to use the Oozie coordinator to trigger an Oozie workflow every
night at midnight ET. The catch is that I need to also pass that time to
my application. I've reworked my tools to take W3C time strings as
property values, but now they're getting times in UTC, not local time.
Here's my coordinator XML file:
<coordinator-app name="my-coord" frequency="${coord:days(1)}"
start="2011-08-30T04:00Z" end="2012-09-01T04:00Z"
timezone="America/New_York"
xmlns="uri:oozie:coordinator:0.1">
<action>
<workflow>
<app-path>${workflowPath}</app-path>
<configuration>
<property>
<name>processingTimeRangeStart</name>
<value>${coord:dateOffset(coord:nominalTime(), -1,
'DAY')}</value>
</property>
<property>
<name>processingTimeRangeEnd</name>
<value>${coord:nominalTime()}</value>
</property>
</configuration>
</workflow>
</action>
</coordinator-app>
This does launch the proper workflow at midnight ET, but tonight it will
specify a processing range from 2011-08-30T04:00Z to 2011-08-31T04:00Z.
Instead, I want it to use one from 2011-08-30T00:00 to 2011-08-31T00:00.
Subtracting four hours by hand will work for now, but at the end of
Daylight Saving Time it will become wrong. Any ideas?
Re: Adjusting for time zone in coordinator EL
Posted by John Armstrong <jo...@ccri.com>.
On Tue, 30 Aug 2011 12:53:50 -0700, Alejandro Abdelnur <tu...@cloudera.com>
wrote:
> John,
>
> You'll get UTC strings. Currently, if you want to convert that to local
> time
> you'll have to do that within your actions.
Ok, thanks for confirming that this isn't within the EL scope.
Re: Adjusting for time zone in coordinator EL
Posted by Alejandro Abdelnur <tu...@cloudera.com>.
John,
You'll get UTC strings. Currently, if you want to convert that to local time
you'll have to do that within your actions.
Thanks.
Alejandro
On Tue, Aug 30, 2011 at 12:45 PM, John Armstrong <jo...@ccri.com>wrote:
> On Tue, 30 Aug 2011 12:38:58 -0700, Alejandro Abdelnur <tu...@cloudera.com>
> wrote:
> > Oozie job submission always expects times in UTC.
>
> Yes, I understand that; I'm asking how to write coordinator EL so that it
> hands the correct local time to my workflow.
>
Re: Adjusting for time zone in coordinator EL
Posted by John Armstrong <jo...@ccri.com>.
On Tue, 30 Aug 2011 12:38:58 -0700, Alejandro Abdelnur <tu...@cloudera.com>
wrote:
> Oozie job submission always expects times in UTC.
Yes, I understand that; I'm asking how to write coordinator EL so that it
hands the correct local time to my workflow.
Re: Adjusting for time zone in coordinator EL
Posted by Alejandro Abdelnur <tu...@cloudera.com>.
John,
Oozie job submission always expects times in UTC.
Thanks.
Alejandro
On Tue, Aug 30, 2011 at 11:49 AM, John Armstrong <jo...@ccri.com>wrote:
> I'm trying to use the Oozie coordinator to trigger an Oozie workflow every
> night at midnight ET. The catch is that I need to also pass that time to
> my application. I've reworked my tools to take W3C time strings as
> property values, but now they're getting times in UTC, not local time.
> Here's my coordinator XML file:
>
> <coordinator-app name="my-coord" frequency="${coord:days(1)}"
> start="2011-08-30T04:00Z" end="2012-09-01T04:00Z"
> timezone="America/New_York"
> xmlns="uri:oozie:coordinator:0.1">
> <action>
> <workflow>
> <app-path>${workflowPath}</app-path>
> <configuration>
> <property>
> <name>processingTimeRangeStart</name>
> <value>${coord:dateOffset(coord:nominalTime(), -1,
> 'DAY')}</value>
> </property>
> <property>
> <name>processingTimeRangeEnd</name>
> <value>${coord:nominalTime()}</value>
> </property>
> </configuration>
> </workflow>
> </action>
> </coordinator-app>
>
> This does launch the proper workflow at midnight ET, but tonight it will
> specify a processing range from 2011-08-30T04:00Z to 2011-08-31T04:00Z.
> Instead, I want it to use one from 2011-08-30T00:00 to 2011-08-31T00:00.
> Subtracting four hours by hand will work for now, but at the end of
> Daylight Saving Time it will become wrong. Any ideas?
>