Answers.Body: <p>Not currently - we should probably add a new 'translate' argument to that function which would let you opt out of it.</p>
  <p>However Craft’s DateTime variables have a <a href="http://buildwithcraft.com/classreference/etc/dates/DateTime#rfc1123-detail" rel="nofollow noreferrer"><code>rfc1123()</code></a> function which can be used instead of the Twig <code>|date</code> filter, and its output won’t get automatically translated.</p>
  <p>For reference, <a href="https://www.rfc-editor.org/rfc/rfc1123" rel="nofollow noreferrer">RFC 1123</a> defines the date/time specification recommended by <a href="https://www.rfc-editor.org/rfc/rfc2616#section-3.3" rel="nofollow noreferrer">RFC 2616 (HTTP 1.1)</a> (which is the same as the one defined by <a href="https://www.rfc-editor.org/rfc/rfc822#section-5" rel="nofollow noreferrer">RFC 822</a>, just with 4-digit years).</p>
  <pre class="lang-twig prettyprint-override"><code>{{ expiry.rfc1123() }}
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-28T15:19:04.380Z
Answers.Text: Great. The date string doesn't look exactly like the date-header, but maybe both is allowed? "Date:Sun, 28 Sep 2014 15:14:58 GMT" vs "Expires:Monday, 29-Sep-14 15:14:58 UTC". Actually .rfc822() looks more like it, but doesn't output the name of the timezone, just the time diff.
Answers.UserDisplayName: André Elvan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-28T17:16:30.873Z
Answers.Text: @AndréElvan Sorry, while the RFC 850 specification should work, apparently it’s obsolete, and RFC 1123 is recommended. Just updated the answer.
Answers.UserDisplayName: Brandon Kelly
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-28T12:14:44.107Z
Answers.LastActivityDate: 2014-09-28T17:15:15.930Z
Answers.LastEditDate: 2021-10-07T07:05:27.390Z
Answers.UserDisplayName: Brandon Kelly
Body: <p>Is there a simple way to opt out of the translation that occurs when you format a date like this:</p>
  
  <pre><code>{{ expiry | date('D, d M Y H:i:s', 'GMT') }}
  </code></pre>
  
  <p>The problem is that I need this in english to create a valid date for my HTTP headers. But the site is in norwegian so days and months are translated, resulting in an invalid date.</p>
  
Tags: <localization><datetime>
Title: Format date without translating text
ThreadText: # Format date without translating text
  
  (Asked by: username_0 on 2014-09-28)
  
  Is there a simple way to opt out of the translation that occurs when you format a date like this:
  
  ```
  {{ expiry | date('D, d M Y H:i:s', 'GMT') }}
  
  ```
  
  The problem is that I need this in english to create a valid date for my HTTP headers. But the site is in norwegian so days and months are translated, resulting in an invalid date.
  
  **Tags:** localization, datetime
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2014-09-28. Score: 2 | Accepted answer
  
  Not currently - we should probably add a new 'translate' argument to that function which would let you opt out of it.
  
  However Craft’s DateTime variables have a [`rfc1123()`](http://buildwithcraft.com/classreference/etc/dates/DateTime#rfc1123-detail) function which can be used instead of the Twig `|date` filter, and its output won’t get automatically translated.
  
  For reference, [RFC 1123](https://www.rfc-editor.org/rfc/rfc1123) defines the date/time specification recommended by [RFC 2616 (HTTP 1.1)](https://www.rfc-editor.org/rfc/rfc2616#section-3.3) (which is the same as the one defined by [RFC 822](https://www.rfc-editor.org/rfc/rfc822#section-5), just with 4-digit years).
  
  ```twig
  {{ expiry.rfc1123() }}
  
  ```
  
  > **Comments:**
  > **username_0**: Great. The date string doesn't look exactly like the date-header, but maybe both is allowed? "Date:Sun, 28 Sep 2014 15:14:58 GMT" vs "Expires:Monday, 29-Sep-14 15:14:58 UTC". Actually .rfc822() looks more like it, but doesn't output the name of the timezone, just the time diff.  
  > **username_1**: @username_0 Sorry, while the RFC 850 specification should work, apparently it’s obsolete, and RFC 1123 is recommended. Just updated the answer.  
  
  ---
  
  