... | ... | @@ -15,7 +15,7 @@ The TIMESTAMP conversion was done so that the front-end interface would require |
|
|
|
|
|
## Proposed solution
|
|
|
|
|
|
totten suggests leaving the existing start and end dates as is, and adding additional columns with the offset information in a decided timezone. This will work best for the consideration of "systems bypassing the API and BAO work under the assumption that they're in the CRM timezone or the timezone doesn't matter."
|
|
|
totten suggests leaving the existing start and end dates ~~as is~~ _in their original form_ (`DATETIME` expressed in _nominal/advertised_ TZ), and adding additional columns with the offset information in a decided timezone. This will work best for the consideration of "systems bypassing the API and BAO work under the assumption that they're in the CRM timezone or the timezone doesn't matter."
|
|
|
|
|
|
Changes required to support timezones:
|
|
|
|
... | ... | |