Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Pig, mail # user - DateTime Proposal Request for Comment

Copy link to this message
Re: DateTime Proposal Request for Comment
Corbin Hoenes 2010-07-02, 21:27
So is your plan to package the jodatime dependency as part of piggybank or will it require 2 REGISTER jar commands one for piggybank and one for joda?

On Jul 2, 2010, at 3:02 PM, Russell Jurney wrote:

> I was planning to rely completely on Jodatime there, and I believe its
> default behavior is to use the local timezone of the machine it is on.  ISO
> time encodes the time zone, and jodatime does the conversions back and
> forth, taking it into account.
> Should this be a pig config field?  You can specify a timezone in jodatime,
> so that should work out ok, it would limit hadoop node shenanigans.
> Russ
> On Fri, Jul 2, 2010 at 1:05 PM, hc busy <[EMAIL PROTECTED]> wrote:
>> I wonder if we can pull timezone support into the system... So some day I
>> can say things like
>> 'jiffies between 11am EST and  13:11 IST'
>> and get back the correct answer in PigLatin.
>> also, how does ISO time know the current time zone?
>> I've seen people run into this situation where the compute node and name
>> node are in different time zones (by accident of course, they're physically
>> in the same room), and it produces some problems that are difficult to
>> track
>> down.
>> so, at least your UnixToISO will need to have some kind of convention for
>> knowing what timezone to send it into, right? What's the plan there?
>> On Thu, Jul 1, 2010 at 11:28 PM, Russell Jurney <[EMAIL PROTECTED]
>>> wrote:
>>> I though I would ping pig-user about this to get comments.  I put a
>>> proposal
>>> for builtin date functions I can have ready for Pig 0.8 at
>>> http://issues.apache.org/jira/browse/PIG-1430
>>> There are so many classes to add a type, given my time constraints I
>> don't
>>> see the benefit of a full datetime type over this proposal right now.
>>> These
>>> functions should be backwards compatible with a full-blown datetime type.
>>> Russ