flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maurice Amsellem <maurice.amsel...@systar.com>
Subject RE: Date and Time with TZ discussion
Date Wed, 09 Oct 2013 12:16:19 GMT
Paul Hastings said:
> really curious to see what folks have done to solve this.

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:

- There are two cases I need to handle:
	1) TZ+DST date/time that come from the server
	2) TZ+DST management for date/time that are created locally in Flex (eg. Date/Time UI components,
 chart legends, etc...) and that needs to be "processed" .

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.

- 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 "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 anticipation" , so I load some transitions at startup, and others
when  a new TZ is involved (eg. user selection).	
- With that table of transitions in the Flex cache, it's rather straightforward to compute
the actual time zone for any given date and TZ, even local date/time (ie that don't come from
server data). 
That's especially useful for eg. charts labels, but not only.

-----------------
I have also discussed with colleagues that say this is not needed, as the back-end should
do all the dates processing, and Flex just "renders" what is has been given.

What do you think? How did you solve this problem if it happened to you? 

Regards,

Maurice 

-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com] 
Envoyé : mercredi 9 octobre 2013 09:28
À : dev@flex.apache.org; paul.hastings@gmail.com
Objet : RE: Date and Time with TZ discussion

Justin Mclean said:
>And don't forgot the daylight savings time "feature", this comes up again and again in
Adobe's JIRA over the years.

That's what I called "manage DST properly". 
Yes of course, it needs to be managed, otherwise it's not funny :-).

Maurice 

-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : mercredi 9 octobre 2013 09:23
À : dev@flex.apache.org; paul.hastings@gmail.com Objet : Date and Time with TZ discussion

(Moved this topic on itw own thread and summed up the answers so far, so that we can continue
the discussion)

Maurice 

-----Message d'origine-----
De : Paul Hastings [mailto:paul.hastings@gmail.com] Envoyé : mercredi 9 octobre 2013 06:34
À : dev@flex.apache.org Objet : Re: Date without Time (Was: Re: Adobe Bugbase: Bug 3643917
Updated: Date/time gets messed up by the client locale time zone setting)



On 10/9/2013 7:04 AM, Michael A. Labriola wrote:
>> Besides of the "Date without time" issue, there is also the issue 
>> handling regular Date+Time in different TZ.
>
> That's a lot more difficult, especially, as you mention because of DST 
> as it requires data tables to make those decisions historically.
>
> I think the only way you can achieve this is changing every hard 
> dependency in Flex on Date to use an interface type.

i find it somehow comforting that i'm not alone in timezone hell ;-)

for "historical" dates we've used calls back to the server (coldfusion) or during data retrieval
where we could access the whole tz database. but the issue then became what's "historical"?
which ended up as "whatever the client said it was", not the best approach.

really curious to see what folks have done to solve this.

____________________________________________________

Justin Mclean wrote:

Hi,

> Besides of the "Date without time" issue, there is also the issue handling regular Date+Time
in different TZ.
And don't forgot the daylight savings time "feature", this comes up again and again in Adobe's
JIRA over the years.

Thanks,
Justin

___________________________________________________

Michael Labriola wrote:

>Besides of the "Date without time" issue, there is also the issue handling regular Date+Time
in different TZ.

That's a lot more difficult, especially, as you mention because of DST as it requires data
tables to make those decisions historically. 

I think the only way you can achieve this is changing every hard dependency in Flex on Date
to use an interface type.

Mike
___________________________________________________
Maurice Amsellem wrote:

Hi,
Besides of the "Date without time" issue, there is also the issue handling regular Date+Time
in different TZ.
The requirement is to be able to do Math on Date+Time locally (not on the java side) that
is TZ aware, and manage DST properly.
I spent several months working on it and from what I understand, others did the same.
- What were the business requirements ?
- What techniques did people use to met the requirements ?
- Could we imagine having a decent implementation of this in pure Flex,  something like a
partial porting of eg. JodaTime to Flex ?
-  Is it "feasible" to change all the time-aware Flex components ( DateField, DateChooser,
Charts, etc.) so that they can use Date or something else (maybe through an interface as suggested
in this thread) ?

Maybe I should open another thread on that, not to pollute this one.

Regards,

Maurice

Mime
View raw message