• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Timestamp Inconsistency

#1
Exclamation 
Having recently experimented with time zones, I find there is an inconsistency in the way CI handles its timestamps (mostly used in $useSoftDeletes / $createdField functionality):

The code in Model.php that handles the timestamps is as follows:
Code:
protected function setDate(int $userData = null)
{
  $currentDate = is_numeric($userData) ? (int) $userData : time();

  switch ($this->dateFormat)
  {
    case 'int':
      return $currentDate;
    case 'datetime':
      return date('Y-m-d H:i:s', $currentDate);
    case 'date':
      return date('Y-m-d', $currentDate);

Case 'int' returns the time in UTC (GMT) whereas 'datetime' and 'date' both return the time in localized time... which makes it a horrible can of worms to manage in the application code if one has users in more than one time zone (or a user reconfigures their time zone).

I'd propose EITHER:

1) standardizing it (and conform to what some believe is 'best practice') to always NOT use zone'd timestamps (ie: making the same timestamp as 'int' be returned in all cases- easily done by using gmdate() in place of the two date() functions.

or

2) add two new (additional) cases, which would make it backward-compatible with what currently exists:
Code:
case 'datetime_utc':
      return gmdate('Y-m-d H:i:s', $currentDate);
case 'date_utc':
      return gmdate('Y-m-d', $currentDate);

Personally, I find 2) less desirable because it leans toward making what should be the 'standard' (and consistent) response a special case. I'd propose implementing 1) and then, if local time options were still desired, implement those as the special cases, perhaps with 'datetime_local' and 'date_local' options.
Reply

#2
I agree that the resultant values for either time format should be equivalent. In my opinion every use of time in the framework should be run through I18n\Time and that way we can handle time zone preferences centrally. Time zones always end up being a pretty big mess, as any app essentially has four working versions: user, server, database, UTC. Standardizing to UTC helps but isn’t always an option.
Reply

#3
Great!... does that mean this will be pushed into one of the upcoming revisions? Smile
Reply

#4
As pointed out - the database may also be in another timezone. For MySQL I always do a "SET time_zone='+00:00'" after connecting to the database and then make sure all times are handled in UTC and only changed when presented to the user (based on the user's timezone settings).
Reply

#5
(09-12-2020, 10:39 AM)tgix Wrote: As pointed out - the database may also be in another timezone. For MySQL I always do a "SET time_zone='+00:00'" after connecting to the database and then make sure all times are handled in UTC and only changed when presented to the user (based on the user's timezone settings).

Yes, this is certainly the best way to keep it from becoming a kidney stone to keep a handle on... (and hence, from what I can tell, generally believed to be best practice).

My thinking has always been to remove the 'database' from the equation by never permitting the 'database' to write time-based values (for example by doing things like having current_time() as a default for a field)... and if there is time-based functionality/jobs to be run on the database, then these are effectively done independently of the data (time values in the data), and based on the time of the 'database' (which, yes, for me is typically also set to UTC anyway).  This way, the 'server' is the only place I've needed to watch for it always referencing UTC when it writes to the database.  All my recovery of the data for the user is typically done in an instance of the server configured to the user's time zone.

It's quite likely that this approach couldn't be used in every situation... and possibly some folk aren't intimidated by kidney stones (?).
Reply


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.