2017-12-29, 05:36 PM
I am setting up mybb on my site and have run into issues dealing with time values. All users and the board itself will be using GMT -5. That value has been set as both the board default and the default for all users.
I was using a plugin that displayed all upcoming events and saw some oddities with respect to time. So I investigated further. For testing purpose, I changed the system output string for "date" to include the hour and TZ ("m/d/y H:i T"). I also at one point output the value returned by date_default_timezone_get.
The default timezone setting is correct ("EST5EDT"). The value output for my_date($mybb->settings['dateformat'], TIME_NOW, 0, 0); is the correct time although reported in the wrong TZ (16:36 GMT which is accurate but not reported as 11:38 EST which is the desired TZ). If I look at the time of a posting, posted at the time referenced above, it gets reported as 11:38 GMT which is both the wrong time but also reported in the wrong TZ (but if one is not looking at the TZ the time looks accurate).
Calendar dates present a problem that is more than cosmetic. If I look at dates associated with calendar items, a single day calendar item will have its associated date be at mm/dd/yy,00:00 GMT but a repeated event starting at 00:00 (or having an empty start/end time) will have it associated date be mm/dd/yy,05:00 GMT (this is because when ente4ed, a repeated event has a TZ associated with it but a single day event just assumes a TZ of GMT).
My head is spinning from all the kludges that appear to have been implented to make the code work properly most of the time. But if my quick look at the design is somewhat close to accurate, I submit this is a nightmare that begs for correction.
Preserving data type integrity matters. A function designed to take an date value in GMT should only be passed a date value that represent GMT. Subtracting 5 hours from a GMT value produces an earlier GMT value, not an EST value. It appears date/time values are stored in the data base as GMT values (which is DEFINITELY what should happen). There is a function my date that converts date/time values to strings but does so improperly. That function takes a GMT value, adjusts that GMT value by the time zone offset, then uses the gmdate function to converts a (now wrong) GMT value into a GMT string. Instead, the date (not gmdate) function should be used to convert the GMT value into a string for the timezone specified by date_default_timezone_get (which should be the BB default timezone, or the timezone of the user if different). In addition, rather than relying on all code dealing with calendar events to treat the start time of a "single day event" differently than a repeating day event, the start time of a single day event should be accurate as time 00:00 on that day for the correct time zone (the user or BB defult as is appropriate). Currently it is time 00:00 in GMT regardless of the default.
To summarize, to keep things simple, all integer values representing date/times should be a GMT value. When that GMT value needs to be output, it can be converted to a string appropriate for the TZ to be used using the date and date_default_timezone_set functions as needed.
I was using a plugin that displayed all upcoming events and saw some oddities with respect to time. So I investigated further. For testing purpose, I changed the system output string for "date" to include the hour and TZ ("m/d/y H:i T"). I also at one point output the value returned by date_default_timezone_get.
The default timezone setting is correct ("EST5EDT"). The value output for my_date($mybb->settings['dateformat'], TIME_NOW, 0, 0); is the correct time although reported in the wrong TZ (16:36 GMT which is accurate but not reported as 11:38 EST which is the desired TZ). If I look at the time of a posting, posted at the time referenced above, it gets reported as 11:38 GMT which is both the wrong time but also reported in the wrong TZ (but if one is not looking at the TZ the time looks accurate).
Calendar dates present a problem that is more than cosmetic. If I look at dates associated with calendar items, a single day calendar item will have its associated date be at mm/dd/yy,00:00 GMT but a repeated event starting at 00:00 (or having an empty start/end time) will have it associated date be mm/dd/yy,05:00 GMT (this is because when ente4ed, a repeated event has a TZ associated with it but a single day event just assumes a TZ of GMT).
My head is spinning from all the kludges that appear to have been implented to make the code work properly most of the time. But if my quick look at the design is somewhat close to accurate, I submit this is a nightmare that begs for correction.
Preserving data type integrity matters. A function designed to take an date value in GMT should only be passed a date value that represent GMT. Subtracting 5 hours from a GMT value produces an earlier GMT value, not an EST value. It appears date/time values are stored in the data base as GMT values (which is DEFINITELY what should happen). There is a function my date that converts date/time values to strings but does so improperly. That function takes a GMT value, adjusts that GMT value by the time zone offset, then uses the gmdate function to converts a (now wrong) GMT value into a GMT string. Instead, the date (not gmdate) function should be used to convert the GMT value into a string for the timezone specified by date_default_timezone_get (which should be the BB default timezone, or the timezone of the user if different). In addition, rather than relying on all code dealing with calendar events to treat the start time of a "single day event" differently than a repeating day event, the start time of a single day event should be accurate as time 00:00 on that day for the correct time zone (the user or BB defult as is appropriate). Currently it is time 00:00 in GMT regardless of the default.
To summarize, to keep things simple, all integer values representing date/times should be a GMT value. When that GMT value needs to be output, it can be converted to a string appropriate for the TZ to be used using the date and date_default_timezone_set functions as needed.