Just some ideas ... I think it will be useful also to include the timezone in the party entity. If a party(=customer) does not have any user associated (which will be usual for non-ecommerce based companies) then we can't address the use case Adrian describes. Even better will be to associate timezones with GeoData. -- Daniel
David E Jones escribió: > > You mention persisting settings in both the Party and UserLogin > entities. On this I think it would be more consistent to just use the > UserLogin entity as it has the lastLocale, etc and we could just add a > lastTimeZone or the like. > > I agree it makes sense to be able to set and change this and use it > for time entry and for calendar display. > > This looks like a bit of work... it's great that you're looking into > it and please let everyone know if you run into any funny issues or > need help with changing a bunch of stuff. > > -David > > > Adrian Crum wrote: >> Okay, the UtilDateTime.java class has been updated to support locales >> and time zones. That is the first step toward addressing the issue in >> this thread. >> >> Now the question is, how and where do we persist the time zone? >> Vinay's original question implied (and I may be wrong) that he needed >> to assign time zones to parties. My use of time zones is more >> user-oriented (for an online calendar program). This same type of use >> can be found in the Workeffort calendar application. >>
