5

First define an array of all the timezones you want to output the time with, plus what their “Standard Time”/“Daylight Savings time” abbreviations are: {% set locales = [ { timezone: 'Australia/Sydney', stAbbr: 'AEST', dstAbbr: 'AEDT' }, { timezone: 'America/Los_Angeles', stAbbr: 'PST', dstAbbr: 'PDT' }, { timezone: 'America/New_York', ...


5

{{ now|date("H:i", "Europe/Paris") }} As per: http://twig.sensiolabs.org/doc/filters/date.html


4

You set it to whatever timezone the content authors will be in, so for example, when they say an entry’s post date is at 10 AM, Craft knows which timezone that should refer to.


4

It is possible to work around the Craft 2 bug, by converting the Craft DateTime object to a native one. {% set craftDateTime = entry.postDate %} {% set nativeDateTime = date(craftDateTime|date('c')) %} {{ nativeDateTime|date('n/d/Y g:ia', 'America/Los_Angeles') }}


3

100% untested, but something like this should work: Have your model override BaseModel's populateModel. Find the DateTime field you're interested in and get its value. Create a new DateTime object and pass in the value from the timeZone attribute. Set the new DateTime object back on the original DateTime field. Call parent::populateModel($values).


3

This is from the Craft Documentation about Date/Time Fields: Note: Dates and times [...] are displayed in the site’s timezone, however they get stored in UTC like all other dates in Craft. Additionally you can also use the date filter, which allows you to specify a different timezone for the output (list of supported timezones). If you want to bind a ...


3

You can set the site's timezone in Craft, but you won't get different timezones for your locales with that (locales != timezones btw.). But what you can do is to use Twig's |date filter which allows you to specify a different timezone for the output (list of supported timezones). If you create your own DateTime object by joining strings, you have to add a ...


2

This is a known Craft 2 bug in our overridden implementation of PHP's DateTime class and how Twig interacts with it. It should be fixed before the Craft 3 beta launch because it is on our list to stop overriding that class and rely on PHP's native functionality.


2

The above code example works. Short and simple answer: daylight saving time (DST) Standard time: -1 hour in database Daylight saving time: -2 hours in database


2

This sounds like that CalFileParser library you are using has some issues with timezones. There is a pull-request that supposedly fixes these, but I would rather exchange it for another library. https://github.com/u01jmg3/ics-parser has the more modern codebase, seems to be actively maintained, more used, and can be installed using composer.


1

Use ini_get('date.timezone'). Source: http://php.net/manual/en/function.ini-get.php


1

Solved. Presumably this was a bug. An update just hit for Craft CMS 3.7.9 which states in the release notes "Fixed a bug where Date fields weren’t handling array values with datetime keys properly. (#9708)". Code now works as expected.


1

I solved that by adding a dropdown field to user profiles where I allowed users to select timezone and then in custom module set the selected timezone like this: class SiteModule extends Module { public function __construct($id, $parent = null, array $config = []) { // Set correct Timezone $currentUser = Craft::$app->getUser(); ...


1

In case this effects anyone else, here's what I did to get working: update craft to latest version (in this case 3.1.24) flush cache using Blitz cache plugin (clear is not enough) use Cloudfront and not just S3 update all asset indexes in cms That seemed to have done the trick.


1

Essentially you're running into this same issue: Using user-selectable timezones to show localized post dates Not terribly pretty, but as a workaround, you can do something like this: {% set start = date("2017-11-09 00:00:00")|date_modify("+7 hours")|date('Y-m-d h:i:s') %} {% set end = date("2017-11-09 23:59:59")|date_modify("+7 hours")|date('Y-m-d h:i:s')...


1

This is going to be a bug in the Store Hours plugin. I've created an issue in the repo here so we can keep track of it: https://github.com/pixelandtonic/StoreHours/issues/3


Only top voted, non community-wiki answers of a minimum length are eligible