I'm planning to get rid of piggybank datetime stuff and make jodatime a core dependency to these builtin functions. No REGISTER required.
Russ On Fri, Jul 2, 2010 at 2:27 PM, Corbin Hoenes <[email protected]> wrote: > 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 > >>> > >> > >
