Improvement to ReadableInstantTranslatorFactory?

48 views
Skip to first unread message

David Fuelling

unread,
Aug 7, 2012, 9:47:40 PM8/7/12
to objectify...@googlegroups.com
Hey Jeff,

I've been using ReadableInstantTranslatorFactory to load/save Joda DateTime objects via Objectify, and noticed that DateTime objects are returned by the Translator using the local timezone of the JVM.  This is not a huge problem -- Joda does the conversion properly.  However, DateTime equality fails when comparing to a DateTime in UTC (which is what I use by default).  This could potentially be solved via @OnLoad/@OnSave callbacks, but for @Embed classes this doesn't work yet.  Additionally, appengine users can't guarantee which TimeZone the JVM will be running in, so returning UTC would seem to be more consistent as a default value.
  
One quick way I could see of doing this in the Translator is to check if the Class type can be cast to an AbstractInstant, which is the parent class of DateTime, DateTimeMidnight, Instant, etc.  Something like this:

Constructor<?> ctor = TypeUtils.getConstructor(clazz, Object.class);
ReadableInstant instance = (ReadableInstant) TypeUtils.newInstance(ctor, value);
if (AbstractInstant.class.isAssignableFrom(clazz))
{
  instance = ((AbstractInstant) instance).toDateTime(DateTimeZone.UTC);
}

return instance;

From what I can tell, all implementations of ReadableInstant extend AbstractInstant, but in the case where one doesn't, the regular ReadableInstant would still be returned (albeit with a Local timezone)

Any strong opinions either way?

Thanks!

david 

Reply all
Reply to author
Forward
0 new messages