<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Firebird: Migration: Time values are being changed during migration process (data type TIME and DATETIME)" href="https://bugs.documentfoundation.org/show_bug.cgi?id=117732#c26">Comment # 26</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Firebird: Migration: Time values are being changed during migration process (data type TIME and DATETIME)" href="https://bugs.documentfoundation.org/show_bug.cgi?id=117732">bug 117732</a> from <a class="email" href="mailto:drewjensen.inbox@gmail.com" title="Drew Jensen <drewjensen.inbox@gmail.com>"> Drew Jensen</a> <pre>(In reply to Tamas Bunth from <a href="show_bug.cgi?id=117732#c25">comment #25</a>) > (In reply to Drew Jensen from <a href="show_bug.cgi?id=117732#c22">comment #22</a>) > > Does anyone think that the correct way would be to use the current OS TZ > > informtion when the migration assistant to change the data so what the user > > sees in the Base UI is the same before and after migration? > > I think it would make sense letting the user decide that. I would suggest a > pop-up dialog right after the user pressed "yes, I want to migrate". This > dialog would appear only if the database contains TIME, DATE, or DATETIME > data types, and it would ask the user if he wants to interpret his data as > (UTC+0) or he would prefer the recalculation of data using OS timezone > information. Yes, asking the user is likely the best solution. Explaining it clearly, succinctly, will probably be the hard part. > > > It is not a big deal to change the values, with a four step process, add > > column, move data with offset fixup, drop the old column, rename the new one > > to match the old. (of course there is any optional steps of dropping and > > recreating things like views and relations that might of used those old > > columns..but) - but big enough that I can easily bet that some of the users > > who would of voted yes above are not going to be happy about that as a > > solution - even with clear examples of how to do it. (which I would be > > willing to put together) > > I agree. A built-in solution is better (like the suggestion above) than a > wiki page describing what to do. > > I would suggest to create a new bug report marked as feature request with > the above changes and close this bug as "won't fix" or "moved" Alright as an new RFE entry then.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>