Add answer to a recurring question re UTC #1257

heiglandreas · 2021-10-23T19:28:01Z

The question "why not to convert to UTC" comes up very frequently so
Larry asked to add the answer to the meta-docs for PSR-20.

The question "why not to convert to UTC" comes up very frequently so Larry asked to add the answer to the meta-docs for PSR-20.

proposed/clock-meta.md

samdark · 2021-10-23T21:02:45Z

proposed/clock-meta.md

+
+### Why not simply convert all times to UTC?
+
+Timezones change! Regularily! And unforseeably! So when you are converting a DateTime in the future to UTC you are using the offset that is known today to convert from the local time to UTC. When that offset changes between now and the datetime then you have no chance to adapt to that. 


If we're talking about timestamp, it's not only timezones. DST is problem by itself for delivery service i.e. you order to deliver a package at day X at 12:00 and that's converted to int. Then DST comes into effect some days before and you get your package either at 11:00 or 13:00 instead of 12:00.

s/Regularily/Regularly/

That is not an issue as that information is encoded into the timezone-information.

Remember: A timezone is a geographical region that is observing the same date and time by governmental definition. Such a timezone is identified by a timezone-identifier such as Europe/Moskow.
Do not confuse timezones with offsets that are defining the difference to the time-standard (which can be either GMT or UTC) or with named offsets like MSK that cover some (but not all) timezones that are observing a certain offset. A timezone can be referenced via different named offsets at different times due to DST changes.

So when using a timezone, the DST information is available. When using an offset then you do not know whether that offset is standard-time or daylight saving time.

proposed/clock-meta.md

hvanoch · 2021-10-29T13:34:48Z

Notice that there is a case when storing the time in local time with timezone can loose information.
Example:

var_dump((new DateTimeImmutable('2021-10-31 00:30:00', new DateTimeZone('UTC')))->setTimeZone(new DateTimeZone('Europe/Brussels')));
var_dump((new DateTimeImmutable('2021-10-31 01:30:00', new DateTimeZone('UTC')))->setTimeZone(new DateTimeZone('Europe/Brussels')));

If we would store 2021-10-31 02:30:00, Europe/Brussels in the database, we would not know if it is before or after DST.

Crell · 2021-10-29T13:59:29Z

@hvanoch Hm. Another fun and exciting problem... I can't tell if that's an argument for or against using UTC, though, just that datetime is fugly. 😄

heiglandreas · 2021-10-29T14:14:06Z

That is indeed correct. And in a perfect world you would store 2021-10-31:2:30:00+01:00, Europe/Brussels in the database. Sadly a technical limitation causes the issue that in PHP we will lose the information due to the fact that there is an RFC open but not yet implemented which would solve this issue. As long as this is not implemented that is indeed an issue. Also entering correct birth dates in currently not supported for i.e. Germany (someone born in the second iteration of the time between 2 and 3 o clock on the morning of the DST back-transition will be born at 2:xx').

As long as it is not supported to call new DateTimeImmutable('2021-10-31 02:30:00+01:00', new DateTimeImmutable('Europe/Berlin')); this one hour is sadly lost.

Nevertheless: this one possible lost hour for future datetimes is much less hassle than converting everything back and forth to and from UTC. And Log-like Information (everything that happens right now can easily be stored in UTC (Yes. it might happen that the calculation from local time to UTC might be broken due to changes that should have been applied now have not yet found their way into the TZDB due to governments thinking one day in advance is enough time for everyone to react)

For the ClockInterface though that is irrelevant as the clock returns a slice of the current time and this one slice will also during the transition backwards return the correct information so when your business-logic calls $clockInterface->now()->getTimestamp() you will get a different timestamp than an hour before or after.

Crell · 2021-12-24T15:46:53Z

The analogy based argument isn't really convincing for me. At this point I've essentially resigned myself to the fact that the timezone will be undefined, but the argument for it needs to be solid enough to avoid 10 years of people whining about it. (See also: PSR-7.) I don't feel like this is.

From advocating the use of local times (which is hard to do for local times) this argumentation moves towards explaining that the interface itself, the explicit contract, does not care about the implementation and with this rather open explicit contract everyone can also implement their own implicit contract to use "UTC" or whatever they want. If they want to. The interface itself is as open as possible while at the same time being as strict as necessary

heiglandreas · 2021-12-29T08:24:12Z

I've redone the argumentation completely away from advocating the use of local time over UTC (which is still a good idea, but kinda hard to convince people that it makes sense even for current date-times) over to trying to make it clear that the interface is as open as possible while at the same time being as strict as necessary. Not enforcing UTC on the explicit contract that the interface defines does not hinder an implicit contract on the implementation level which defines that the interface will always return objects with a certain timezone preset.

proposed/clock-meta.md

samdark

The addition itself is fine. Minor issues are easy to be fixed.

Co-authored-by: Alexander Makarov <[email protected]>

localheinz · 2022-04-20T12:29:04Z

What is the hold-up here - can we move this forward?

BafS · 2022-04-21T08:54:58Z

proposed/clock-meta.md

+use-cases that do require something else will have to explicitly work around that or find other ways of 
+handling the problem, the contract tries to solve as the contract does not fit the needs. This is different 
+from the issue of i.e., immutability which can also not be enforced on the language level but which is
+necessary to adhere to other calls on the contract. IN the case of the `clock`-interface there will be no 


Suggested change

necessary to adhere to other calls on the contract. IN the case of the `clock`-interface there will be no

necessary to adhere to other calls on the contract. In the case of the `clock`-interface there will be no

Typo?

ashnazg

Some of the "English flow" could be tweaked, but content seems good to me.

ashnazg · 2022-07-18T00:43:22Z

@cseufert ping... Github shows you still active in general, so reaching out to you here rather than just on Discord to confirm you're still interested in this PSR... ?

ashnazg · 2022-07-18T01:49:10Z

@cseufert, as Editor, you can merge these, right?

cseufert · 2022-07-18T02:42:34Z

I cant merge it, can only approve it for merging

ashnazg · 2022-07-18T02:53:06Z

I cant merge it, can only approve it for merging

Ok, I'll find out who can, and get both open PRs merged. Thanks for getting them both approved, and welcome back ;-)

Jean85 · 2022-07-18T10:33:53Z

Done, my pleasure! 😄

Add answer to a recurring question re UTC

37a9615

The question "why not to convert to UTC" comes up very frequently so Larry asked to add the answer to the meta-docs for PSR-20.

samdark reviewed Oct 23, 2021

View reviewed changes

proposed/clock-meta.md Outdated Show resolved Hide resolved

samdark reviewed Oct 23, 2021

View reviewed changes

Crell reviewed Oct 24, 2021

View reviewed changes

proposed/clock-meta.md Outdated Show resolved Hide resolved

PowerKiKi reviewed Oct 25, 2021

View reviewed changes

proposed/clock-meta.md Outdated Show resolved Hide resolved

Emphazise reasoning against generic UTC

71b5f44

samdark added the PSR-20: Clock label Nov 27, 2021

Reword the last paragraphs

44555ea

heiglandreas requested review from Crell, ashnazg and samdark December 23, 2021 20:58

heiglandreas force-pushed the addReasonsNotToConvertToUtc branch from aa89846 to d366693 Compare December 29, 2021 08:20

samdark reviewed Jan 6, 2022

View reviewed changes

samdark approved these changes Jan 6, 2022

View reviewed changes

heiglandreas and others added 5 commits January 6, 2022 09:56

Update proposed/clock-meta.md

7497ff4

Co-authored-by: Alexander Makarov <[email protected]>

Update proposed/clock-meta.md

5587453

Co-authored-by: Alexander Makarov <[email protected]>

Update proposed/clock-meta.md

77e6ea1

Co-authored-by: Alexander Makarov <[email protected]>

Update proposed/clock-meta.md

393b66c

Co-authored-by: Alexander Makarov <[email protected]>

Update proposed/clock-meta.md

dd4ae5e

Co-authored-by: Alexander Makarov <[email protected]>

BafS reviewed Apr 21, 2022

View reviewed changes

ashnazg approved these changes Jul 18, 2022

View reviewed changes

cseufert approved these changes Jul 18, 2022

View reviewed changes

Jean85 merged commit 7d0c5d5 into php-fig:master Jul 18, 2022

nicolas-grekas mentioned this pull request Jul 21, 2022

[Clock] A new component to decouple applications from the system clock symfony/symfony#46715

Merged


		### Why not simply convert all times to UTC?

		Timezones change! Regularily! And unforseeably! So when you are converting a DateTime in the future to UTC you are using the offset that is known today to convert from the local time to UTC. When that offset changes between now and the datetime then you have no chance to adapt to that.

	necessary to adhere to other calls on the contract. IN the case of the `clock`-interface there will be no
	necessary to adhere to other calls on the contract. In the case of the `clock`-interface there will be no

Uh oh!

Add answer to a recurring question re UTC #1257

Add answer to a recurring question re UTC #1257

Uh oh!

Conversation

heiglandreas commented Oct 23, 2021

Uh oh!

Uh oh!

samdark Oct 23, 2021

Choose a reason for hiding this comment

Uh oh!

ashnazg Oct 24, 2021

Choose a reason for hiding this comment

Uh oh!

heiglandreas Nov 3, 2021

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

hvanoch commented Oct 29, 2021

Uh oh!

Crell commented Oct 29, 2021

Uh oh!

heiglandreas commented Oct 29, 2021

Uh oh!

Crell commented Dec 24, 2021

Uh oh!

heiglandreas commented Dec 29, 2021

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

samdark left a comment

Choose a reason for hiding this comment

Uh oh!

localheinz commented Apr 20, 2022

Uh oh!

BafS Apr 21, 2022

Choose a reason for hiding this comment

Uh oh!

ashnazg left a comment

Choose a reason for hiding this comment

Uh oh!

ashnazg commented Jul 18, 2022

Uh oh!

ashnazg commented Jul 18, 2022

Uh oh!

cseufert commented Jul 18, 2022

Uh oh!

ashnazg commented Jul 18, 2022

Uh oh!

Jean85 commented Jul 18, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants