Change account timezone

[a...@caravelo.com]

Hello,

I'd need to change the timezone of all (!) accounts of a Kill Bill installation. I know that this operation is unsupported via REST API, so my question is: what is the critical aspect  of changing an account timezone? Is the lack of support related to the complexity of rescheduling all pending notification? Or there are other reasons I cannot see?

Being willing to adopt a dirty solution, how risky could be changing the timezone directly in the DB (accounts table)? If the only drawback would be a misalignment of already scheduled notifications, it could be acceptable for me.

Wanting to update already scheduled notification, how can I associate a notification with corresponding account? Which are all relevant events I should convert and the meaning of event_json object fields?

Thank you very much!

--

Alessio Gaeta

[Pierre-Alexandre Meyer]

At a high level, the timezone is used for converting a local date into a date time and vice versa (http://docs.killbill.io/0.20/invoice_subsystem.html#_reference_time_and_fixed_offset_timezone).

There is significant risk in changing the timezone directly in the DB. Besides "harmless" side effects (e.g. the BCD in the account timezone would shift by a day), there could be more serious ones in the invoicing subsystem (maybe periods double billed or unnecessary repairs if the system gets confused by DST gaps).

If you are already in production, why do you need to change it? Does your application need that timezone information or do you need Kill Bill to change when invoicing happens? If it's for the former, I would suggest to use a custom field on the account instead.

If you do decide to go ahead and change it, export a few accounts in a test environment and verify invoice generation over a long period (e.g. a year), to make sure there are no side effects.

Regarding notifications, the search_key1 column is the account record_id.

This message and its attachments are intended for the exclusive use of the addressee(s) stated above and contains privileged and confidential information. If you have received this message in error, you are on notice of its privileged and confidential status and bound to keep the information in the message and attachments confidential. Please notify the sender immediately and delete this message from your system, making no copy of it.

--
You received this message because you are subscribed to the Google Groups "Kill Bill users mailing-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to killbilling-users+unsubscribe@googlegroups.com.
To post to this group, send email to killbilling-users@googlegroups.com.
Visit this group at https://groups.google.com/group/killbilling-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/killbilling-users/57bd4b22-5854-477c-bcb4-970fa22983f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Pierre

[Alessio Gaeta]

Hello Pierre.

Il giorno 16 lug 2018, alle ore 23:01, Pierre-Alexandre Meyer <pie...@kill-bill.org> ha scritto:

At a high level, the timezone is used for converting a local date into a date time and vice versa (http://docs.killbill.io/0.20/invoice_subsystem.html#_reference_time_and_fixed_offset_timezone).

There is significant risk in changing the timezone directly in the DB. Besides "harmless" side effects (e.g. the BCD in the account timezone would shift by a day), there could be more serious ones in the invoicing subsystem (maybe periods double billed or unnecessary repairs if the system gets confused by DST gaps).

If you are already in production, why do you need to change it? Does your application need that timezone information or do you need Kill Bill to change when invoicing happens? If it's for the former, I would suggest to use a custom field on the account instead.

Well, due to a trivial mistake, we did not set timezone properly from the beginning and now we need to change the time of invoicing. All the accounts have UTC as timezone, but the users are in UTC-5, so the billing happens ahead of time for them.

If you do decide to go ahead and change it, export a few accounts in a test environment and verify invoice generation over a long period (e.g. a year), to make sure there are no side effects.

I’ll try. Should I change the clock a month at a time, or can I set it directly one year ahead?

Regarding notifications, the search_key1 column is the account record_id.

Yes, after writing on the list I started to peek into the code… :)

Thank’s for your time, Pierre, you’re help is very precious! (And Kill Bill too!)

—

Alessio

[Pierre-Alexandre Meyer]

On Tue, Jul 17, 2018 at 8:51 AM, Alessio Gaeta <a...@caravelo.com> wrote:

I’ll try. Should I change the clock a month at a time, or can I set it directly one year ahead?

I would do month to month, to be safe.

Do you have lots of accounts to update? Just wondering if it's easier to re-create them cleanly.

--

Pierre

[Alessio Gaeta]

> Il giorno 17 lug 2018, alle ore 10:30, Pierre-Alexandre Meyer <pie...@kill-bill.org> ha scritto:
>
> Do you have lots of accounts to update? Just wondering if it's easier to re-create them cleanly.

Well, not much, ~3k, but we have metadata in our application DB referring them, so recreating is a no-go, I guess (all ids would change). Unless there is a transparent/clever way to do it.

BTW, the issue has just been put on hold, as it seems not so critical a 5h difference in billing time. Maybe there is no need to intervene. But IMO the scenario is still interesting to understand how Kill Bill works… :)

Thanks!

—
Alessio


--

[Pierre-Alexandre Meyer]

On Tue, Jul 17, 2018 at 12:01 PM, Alessio Gaeta <a...@caravelo.com> wrote:

Well, not much, ~3k, but we have metadata in our application DB referring them, so recreating is a no-go, I guess (all ids would change). Unless there is a transparent/clever way to do it.

Ideally, your application would only store external keys. These are unique per tenant, so you could keep them by recreating the data in another tenant. But it's a bit tedious / error prone...

BTW, the issue has just been put on hold, as it seems not so critical a 5h difference in billing time. Maybe there is no need to intervene. But IMO the scenario is still interesting to understand how Kill Bill works… :)

One other experiment you could try is to upgrade to 0.20.0, change the account reference time in the database (shift by 5 hours) and restart Kill Bill. This might just do the trick (for subsequent invoices, not the very next one though). To be tested...

--

Pierre

[Alessio Gaeta]

One other experiment you could try is to upgrade to 0.20.0, change the account reference time in the database (shift by 5 hours) and restart Kill Bill. This might just do the trick (for subsequent invoices, not the very next one though). To be tested…

I was just reading 0.20 release notes and wondering what is account reference time… It seems promising, I’ll check into it. If you could give me some pointers I would really appreciate!

—

Alessio

[Pierre-Alexandre Meyer]

See http://docs.killbill.io/0.20/invoice_subsystem.html#_reference_time_and_fixed_offset_timezone.

--

Pierre