Outputs time respecting backend preferences

[arvislacis]

Fixes #535

In addition it also fixes the same problem in the theme log detail page.

[mjauvin]

Would it make more sense to actually set the timezone on the Model dates from within the Storm library?

i.e. Database/Model.php (asDateTime() method)

[mjauvin]

I just tested adding backend timezone in Winter\Storm\Database\Model::asDateTime() and it works great.

[mjauvin]

diff --git a/src/Database/Model.php b/src/Database/Model.php
index 9f2666a..8d57d76 100644
--- a/src/Database/Model.php
+++ b/src/Database/Model.php
@@ -1,6 +1,7 @@
 <?php namespace Winter\Storm\Database;
         
 use Closure;
+use Config;
 use Winter\Storm\Support\Arr;
 use Winter\Storm\Support\Str;
 use Winter\Storm\Argon\Argon;
@@ -544,11 +545,13 @@ public function freshTimestamp()
      */
     protected function asDateTime($value)
     {
+        $tz = Config::get('cms.backendTimezone', 'UTC');
+
         // If this value is already a Argon instance, we shall just return it as is.
         // This prevents us having to re-instantiate a Argon instance when we know
         // it already is one, which wouldn't be fulfilled by the DateTime check.
         if ($value instanceof Argon) {
-            return $value;
+            return $value->tz($tz);
         }
 
         // If the value is already a DateTime instance, we will just skip the rest of
@@ -557,7 +560,7 @@ protected function asDateTime($value)
         if ($value instanceof DateTimeInterface) {
             return new Argon(
                 $value->format('Y-m-d H:i:s.u'),
-                $value->getTimezone()
+                $value->getTimezone() ?: $tz
             );
         }
         
@@ -565,14 +568,14 @@ protected function asDateTime($value)
         // and format a Carbon object from this timestamp. This allows flexibility
         // when defining your date fields as they might be UNIX timestamps here.
         if (is_numeric($value)) {
-            return Argon::createFromTimestamp($value);
+            return Argon::createFromTimestamp($value)->tz($tz);
         }   
         
         // If the value is in simply year, month, day format, we will instantiate the
         // Carbon instances from that format. Again, this provides for simple date
         // fields on the database, while still supporting Carbonized conversion.
         if ($this->isStandardDateFormat($value)) {
-            return Argon::createFromFormat('Y-m-d', $value)->startOfDay();
+            return Argon::createFromFormat('Y-m-d', $value)->startOfDay()->tz($tz);
         }
         
         $format = $this->getDateFormat();
@@ -598,7 +601,7 @@ protected function asDateTime($value)
         // Finally, we will just assume this date is in the format used by default on
         // the database connection and use that format to create the Carbon object
         // that is returned back out to the developers after we convert it here.
-        return Argon::createFromFormat($format, $value);
+        return Argon::createFromFormat($format, $value)->tz($tz);
     }   
 
     /** 

[arvislacis]

@mjauvin Yes, I can confirm that your solution works without problems (in Event and Theme log) and it's better one as it solves this issue at Model level.

[mjauvin]

Feel free to submit a PR for the Model class!

[arvislacis]

@mjauvin I did some additional tests on Database/Model.php changes and it doesn't seem to be ok..., date & time is ok in inner Detail page but in the all event list now the datetime is shifted by Timezone value..., also, if new event is added to the list then it seems that timezone value is calculated twice...

The initial problem (#535) was only about incorrect datetime in Event Detail page, lists were working fine.

[mjauvin]

Ok, this might be a breaking change then, please ignore my changes.
@LukeTowers @bennothommo any feedback on this?

[bennothommo]

@arvislacis @mjauvin we would want the dates and times to be stored as UTC in the database. If they are retrieved at the model level as UTC and then converted to a particular timezone, that would be fine, as long as any subsequent save has the date/time converted back to UTC.

Personally, given that the Backend timezone is specifically a backend preference, I think it would be better to keep the timezone shifting out of the model, because that would then happen everywhere - including on the CMS side. Hence, I would prefer the changes happen in the partials as per @arvislacis' original changes.

[LukeTowers]

We should probably use the \Backend::dateTime($carbon) helper instead here.

[arvislacis]

@LukeTowers In the last commit made changes to use \Backend::dateTime($carbon). In additional this change has a benefit that it outputs Event time in local datetime format (previously it was always outputted in English, even I don't have English language/locale set in the back-end preferences).

[arvislacis]

Anything specific needed for this to be merged?

I think my last commit - ed29d81 - on this contains pretty simple fix which should no cause any problems.

[LukeTowers]

Looks good, thanks @arvislacis!