On 10/9/2013 7:16 PM, Maurice Amsellem wrote:
This is the approach I have taken to solve this, that successfully addresses my requirements (monitoring apps for world-wide Banks with offices in different continents). I don't know if it makes sense to other usages, but I think you could be interested:
yes, thanks for the info. i'm often obsessed w/tz stuff.
Regarding case 2): - I am relying on Joda-Time on the back-end (http://www.joda.org/joda-time/) to manage TZ and DST changes.
we looked at joda but their i18n bits were lacking (this was quite a while ago). might need another look but not seeing a lot of activity on their list.
- Since it's out of question to do a remote call on-the-fly for every date object that needs to be processed (async and perf issues), so I am
for large chunks of data, yes. our case wasn't so much (results of some models that were run very rarely). and as it turned out 90% of the usage was here in thailand, which doesn't have DST.
"uploading" the internal TZ transitions from Joda-Time to Flex, using org.joda.time.DateTimeZone.nextTransition(dateLong) - I don't upload the whole transition tables for all TZs, but only for the TZ that are actually used, and for a large enough date range, ie current date + 5 years /- 5 years, and maintain a cache on the Flex side. - I need to do that "in
icu4j (which we rely on for i18n bits especially calendars & install most of the time) has this functionality. i'll have to give this approach a try.
thanks again for the info.
