View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
---|---|---|---|---|---|---|---|---|---|
0001521 | v3.2 Release | Events | public | 2014-05-06 13:40 | 2014-07-16 21:29 | ||||
Reporter | opto | ||||||||
Assigned To | caseydk | ||||||||
Priority | normal | Severity | minor | Reproducibility | have not tried | ||||
Status | closed | Resolution | fixed | ||||||
Product Version | |||||||||
Target Version | 3.2 | Fixed in Version | 3.2 | ||||||
Summary | 0001521: inconsistency in event logic | ||||||||
Description | CEvent->load(id) followed by store() changes the times. (to UTC). Logically, that is highly undesirable. Any object that has been loaded should be possible to be stored without changing any of its fields. It seems load delievers times in mysql TZ and store expects them in user TZ. one needs to read the times from the event and convert them back from mysql TZ to user TZ before storing. Even if times have not been touched, only description or similiar. Eventually, it might be nice to have a event_TZ field to prevent such a problem. That could indicate in which TZ the CEvent holds the times and could be used on store to determine what to do. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files |
|
![]() |
|
caseydk (administrator) 2014-05-09 15:31 |
Resolved in development: https://github.com/web2project/web2project/commit/7cd2b09b6ca7ed5c990a17bc55d6b516d14072c5 |
![]() |
|||
Date Modified | Username | Field | Change |
---|---|---|---|
2014-05-06 13:40 | opto | New Issue | |
2014-05-09 00:21 | caseydk | Assigned To | => caseydk |
2014-05-09 00:21 | caseydk | Status | new => assigned |
2014-05-09 15:31 | caseydk | Note Added: 0003356 | |
2014-05-09 15:31 | caseydk | Status | assigned => resolved |
2014-05-09 15:31 | caseydk | Resolution | open => fixed |
2014-05-25 20:28 | caseydk | Relationship added | related to 0001522 |
2014-06-10 22:09 | caseydk | Target Version | => 3.2 |
2014-07-16 21:26 | caseydk | Fixed in Version | => 3.2 |
2014-07-16 21:29 | caseydk | Status | resolved => closed |