Timeline for DrupalDateTime::createFromFormat() returns the wrong time value
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 28, 2022 at 8:39 | comment | added | avpaderno♦ | @mpdonadio Yes, Unix timestamps use UTC, but that is different from the class that ignores the timezone when it gets a timestamp. Using procedural code, you would not get that behavior. (That's how the PHP class behaves, though, and the Drupal class inherits it.) | |
| Jun 27, 2022 at 7:25 | history | edited | 4uk4 | CC BY-SA 4.0 |
added 480 characters in body
|
| Jun 27, 2022 at 7:20 | history | edited | 4uk4 | CC BY-SA 4.0 |
added 480 characters in body
|
| Jun 25, 2022 at 18:51 | comment | added | mpdonadio♦ | @Kevin Unix timestamps by definition are the number of seconds (minus leap second) since 00:00:00 UTC on 1 January 1970. Internally, Drupal does everything in UTC ; time zones are an input/output thing. | |
| Jun 25, 2022 at 13:19 | history | edited | 4uk4 | CC BY-SA 4.0 |
added 233 characters in body
|
| Jun 25, 2022 at 13:18 | comment | added | 4uk4 | In this case the mentioned internal timestamp is exactly what you are looking for, see the edit. | |
| Jun 25, 2022 at 13:17 | comment | added | 4uk4 | Yes, this is fair to say. The regional settings affect how dates are entered and displayed. Storage is always UTC, also for complex date fields. | |
| Jun 25, 2022 at 12:55 | comment | added | Kevin | Updated OP. The goal is to query for nodes created Monday to Monday, which only happens in this timezone in EDT. No storage or saving. | |
| Jun 25, 2022 at 12:33 | comment | added | Kevin | Is it fair to say entity created/changed timestamps are in UTC, then? For some reason I thought the Regional date setting in the admin may have affected this. | |
| Jun 25, 2022 at 11:23 | history | answered | 4uk4 | CC BY-SA 4.0 |