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.amsel...@systar.com]
Envoyé : mercredi 9 octobre 2013 09:28
À : dev@flex.apache.org; paul.hasti...@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.amsel...@systar.com]
Envoyé : mercredi 9 octobre 2013 09:23
À : dev@flex.apache.org; paul.hasti...@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.hasti...@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
