Re: [PHP-DEV] DateTimeZone silently falls back to UTC when providing seconds

2021-09-13 Thread Pierre 

Le 13/09/2021 à 14:06, Andreas Heigl a écrit :

Hey

What use-case does it serve to allow offsets that are not reflected in 
the TZDB? 


Yes there are use cases:

 * Your TZDB is obsolete, your hardware and OS is obsolete, but the
   prod is still running (it happens more than you think).
 * You don't care about the TZ name and just use offsets (it happens
   also, happened to me not so long ago I needed to convert dates with
   arbitrary offset from some storage).
 * You fetch dates from a storage which doesn't care about time zone
   names (hello any SQL database), for example pgsql doesn't store
   offsets only UTC time, but it accepts arbitrary offsets as input,
   regarding output dates converted to the explicitly asked time zone
   or client connection time zone (so actually you this is not a valid
   use case, but I wanted to highlight that pgsql accepts any arbitrary
   offset).
 * You fetch broken dates with broken timezone from a broken storage,
   but you have to deal with those dates one way or another.

There as many good reasons for accepting arbitrary offset that there are 
offsets on each, so basically that 24*60 good reasons.


That's my opinion, as being confronted with dates problems quite often.

Just for fun, some pgsql random select:

db=# select timestamp with time zone '2021-09-13 14:24:00+03:15' at time 
zone 'utc';

  timezone
-
 2021-09-13 11:09:00

Regards,

--

Pierre

Re: [PHP-DEV] DateTimeZone silently falls back to UTC when providing seconds

2021-09-13 Thread Andreas Heigl 

Hey

On 13.09.21 13:32, Hans Henrik Bergan wrote:

What use-case does that serve?


if some country want to change their timezone for whatever reason, to some
timezone that didn't exist previously, could happen at any time really


I'm well aware that that could happen at any time really. And I'm well 
aware that "at any time" also can mean "By the way, we changed 14 days ago".


But what does that mean? That means that there are different possibilities:

1. The change was announced well in advance and therefore there is a 
TZDB release that already reflects that change. So whatever timezone we 
are talking about: The modification is already available and can be used 
via the [continent]/[city] identifier. And if we would allow all 
existing offsets to be used, that one would also be available.


2. The change was not announced well in advance, so that there is no 
TZDB release that reflects that change when it goes "live". You PHP 
application is the least concern you have. Because the change is not 
reflected *anywhere*. Not on your server, not on your database, not on 
the users mobiles not on the users desktops, not in their smartwatches: 
nowhere.* Yes: You would then be able to allow people to enter the 
offset instead of letting them comfortably select a location near them 
and extrapolate the timezone (or offset if it must be) from that. But 
you are then handling data that is not officially registered, could 
possibly change and might break in the future due to some differences 
that the official sources defined but your user didn't know about. That 
is a rabbit hole that I would not want to get into and that we should 
not encourage to get into. And which is currently open and seems to be 
in need of fixing.


For completeness sake there is a further option: The change was 
announced well in advance but you did not yet update your PHP-version or 
the timezonedb pecl package. Do so! Preferably the former but if that is 
not an option at least the later!


So my question still stands:

What use-case does it serve to allow offsets that are not reflected in 
the TZDB?


Again: Just my 0.02 €

Cheers

Andreas

* That almost happened some years ago. IIRC the government actually 
postponed the change so the TZDB and all the upstream vendors could react.


On Sun, 12 Sept 2021 at 13:06, Andreas Heigl  wrote:


Hey Benjamin, Hey All

On 11.09.21 23:58, Benjamin Morel wrote:



Before doing so, shouldn't we discuss whether it makes sense to accept
a
time-zone offset with seconds, when the granularity seems to be 15
mins?

https://en.wikipedia.org/wiki/List_of_UTC_time_offsets

— Benjamin


No need. Early timezone offsets in the timezone database are in LMT

(local

mean time), which have second granularity.

cheers,
Derick



Hi, sorry for resurrecting an old thread, but now that this bug
 has been fixed in PHP 8.0.10, I

can

see that seconds have been forbidden from DateTimeZone altogether:

https://3v4l.org/QpSln

Before forbidding seconds in brick/date-time's *TimeZoneOffset* as well
(and going against JSR-310, which this library was derived from), can I
please know why this decision was made, when as I understand it, this

goes

against your statement above?


For me the more interesting question is: "Why would one allow to create
any arbitrary Timezone-object using any offset at all?"

Currently it is even possible to declare a Timezone Object with an
Offset that has never been used anywhere on the globe. So for example
`new DateTimezone(`+11:32`) is completely valid from a coding point of
view but not from a timezone point of view. What use-case does that serve?

If one has to create a timezone-object for an existing timezone one can
create that either via `new DateTimezone('Continent/Whatever')` or via
`new DateTimezone('Etc/GMT+XX')` or via `new DateTimezone('PST')`.

This does currently not support creating offset-based timezone-objects
for areas such as Nepal or India that use an offset that currently can't
be declared via the `Etc`-Identifiers.

So a different approach would be to only support type 1 offsets that are
known to the TZDB. Everything else (including arbitrary seconds) should
result in an exception.

So I can understand to not allow arbitrary seconds at all. But IMO we
should then also not allow arbitrary minutes also.

But that's just my 0.02 €

Cheers

Andreas
--
,,,
   (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org   |
+-+
| https://hei.gl/appointmentwithandreas   |

Re: [PHP-DEV] DateTimeZone silently falls back to UTC when providing seconds

2021-09-13 Thread Hans Henrik Bergan 
>What use-case does that serve?

if some country want to change their timezone for whatever reason, to some
timezone that didn't exist previously, could happen at any time really

On Mon, 13 Sept 2021 at 13:32, Hans Henrik Bergan 
wrote:

> > What use-case does that serve?
>
> if some country want to change their timezone for whatever reason, to some
> timezone that didn't exist previously, could happen at any time really
>
> On Sun, 12 Sept 2021 at 13:06, Andreas Heigl  wrote:
>
>> Hey Benjamin, Hey All
>>
>> On 11.09.21 23:58, Benjamin Morel wrote:
>> >>
>> >>> Before doing so, shouldn't we discuss whether it makes sense to accept
>> >>> a
>> >>> time-zone offset with seconds, when the granularity seems to be 15
>> >>> mins?
>> >>>
>> >>> https://en.wikipedia.org/wiki/List_of_UTC_time_offsets
>> >>>
>> >>> — Benjamin
>> >>
>> >> No need. Early timezone offsets in the timezone database are in LMT
>> (local
>> >> mean time), which have second granularity.
>> >>
>> >> cheers,
>> >> Derick
>> >
>> >
>> > Hi, sorry for resurrecting an old thread, but now that this bug
>> >  has been fixed in PHP 8.0.10,
>> I can
>> > see that seconds have been forbidden from DateTimeZone altogether:
>> >
>> > https://3v4l.org/QpSln
>> >
>> > Before forbidding seconds in brick/date-time's *TimeZoneOffset* as well
>> > (and going against JSR-310, which this library was derived from), can I
>> > please know why this decision was made, when as I understand it, this
>> goes
>> > against your statement above?
>>
>> For me the more interesting question is: "Why would one allow to create
>> any arbitrary Timezone-object using any offset at all?"
>>
>> Currently it is even possible to declare a Timezone Object with an
>> Offset that has never been used anywhere on the globe. So for example
>> `new DateTimezone(`+11:32`) is completely valid from a coding point of
>> view but not from a timezone point of view. What use-case does that serve?
>>
>> If one has to create a timezone-object for an existing timezone one can
>> create that either via `new DateTimezone('Continent/Whatever')` or via
>> `new DateTimezone('Etc/GMT+XX')` or via `new DateTimezone('PST')`.
>>
>> This does currently not support creating offset-based timezone-objects
>> for areas such as Nepal or India that use an offset that currently can't
>> be declared via the `Etc`-Identifiers.
>>
>> So a different approach would be to only support type 1 offsets that are
>> known to the TZDB. Everything else (including arbitrary seconds) should
>> result in an exception.
>>
>> So I can understand to not allow arbitrary seconds at all. But IMO we
>> should then also not allow arbitrary minutes also.
>>
>> But that's just my 0.02 €
>>
>> Cheers
>>
>> Andreas
>> --
>>,,,
>>   (o o)
>> +-ooO-(_)-Ooo-+
>> | Andreas Heigl   |
>> | mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
>> | https://andreas.heigl.org   |
>> +-+
>> | https://hei.gl/appointmentwithandreas   |
>> +-+
>>
>

Re: [PHP-DEV] DateTimeZone silently falls back to UTC when providing seconds

2021-09-12 Thread Andreas Heigl 

Hey Benjamin, Hey All

On 11.09.21 23:58, Benjamin Morel wrote:



Before doing so, shouldn't we discuss whether it makes sense to accept
a
time-zone offset with seconds, when the granularity seems to be 15
mins?

https://en.wikipedia.org/wiki/List_of_UTC_time_offsets

— Benjamin


No need. Early timezone offsets in the timezone database are in LMT (local
mean time), which have second granularity.

cheers,
Derick



Hi, sorry for resurrecting an old thread, but now that this bug
 has been fixed in PHP 8.0.10, I can
see that seconds have been forbidden from DateTimeZone altogether:

https://3v4l.org/QpSln

Before forbidding seconds in brick/date-time's *TimeZoneOffset* as well
(and going against JSR-310, which this library was derived from), can I
please know why this decision was made, when as I understand it, this goes
against your statement above?


For me the more interesting question is: "Why would one allow to create 
any arbitrary Timezone-object using any offset at all?"


Currently it is even possible to declare a Timezone Object with an 
Offset that has never been used anywhere on the globe. So for example 
`new DateTimezone(`+11:32`) is completely valid from a coding point of 
view but not from a timezone point of view. What use-case does that serve?


If one has to create a timezone-object for an existing timezone one can 
create that either via `new DateTimezone('Continent/Whatever')` or via 
`new DateTimezone('Etc/GMT+XX')` or via `new DateTimezone('PST')`.


This does currently not support creating offset-based timezone-objects 
for areas such as Nepal or India that use an offset that currently can't 
be declared via the `Etc`-Identifiers.


So a different approach would be to only support type 1 offsets that are 
known to the TZDB. Everything else (including arbitrary seconds) should 
result in an exception.


So I can understand to not allow arbitrary seconds at all. But IMO we 
should then also not allow arbitrary minutes also.


But that's just my 0.02 €

Cheers

Andreas
--
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org   |
+-+
| https://hei.gl/appointmentwithandreas   |
+-+


OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PHP-DEV] DateTimeZone silently falls back to UTC when providing seconds

2021-09-11 Thread Benjamin Morel 
>
> >Before doing so, shouldn't we discuss whether it makes sense to accept
> >a
> >time-zone offset with seconds, when the granularity seems to be 15
> >mins?
> >
> >https://en.wikipedia.org/wiki/List_of_UTC_time_offsets
> >
> >— Benjamin
>
> No need. Early timezone offsets in the timezone database are in LMT (local
> mean time), which have second granularity.
>
> cheers,
> Derick


Hi, sorry for resurrecting an old thread, but now that this bug
 has been fixed in PHP 8.0.10, I can
see that seconds have been forbidden from DateTimeZone altogether:

https://3v4l.org/QpSln

Before forbidding seconds in brick/date-time's *TimeZoneOffset* as well
(and going against JSR-310, which this library was derived from), can I
please know why this decision was made, when as I understand it, this goes
against your statement above?

Thanks in advance,
- Benjamin

Re: [PHP-DEV] DateTimeZone silently falls back to UTC when providing seconds

2021-05-30 Thread Derick Rethans 
On 30 May 2021 23:18:31 BST, Benjamin Morel  wrote:
>>
>> I can't think of why this couldn't work. Duke a bug report please at
>> bugs.php.net?
>
>
>Before doing so, shouldn't we discuss whether it makes sense to accept
>a
>time-zone offset with seconds, when the granularity seems to be 15
>mins?
>
>https://en.wikipedia.org/wiki/List_of_UTC_time_offsets
>
>— Benjamin

No need. Early timezone offsets in the timezone database are in LMT (local mean 
time), which have second granularity.

cheers,
Derick

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] DateTimeZone silently falls back to UTC when providing seconds

2021-05-30 Thread Benjamin Morel 
>
> I can't think of why this couldn't work. Duke a bug report please at
> bugs.php.net?


 Before doing so, shouldn't we discuss whether it makes sense to accept a
time-zone offset with seconds, when the granularity seems to be 15 mins?

https://en.wikipedia.org/wiki/List_of_UTC_time_offsets

— Benjamin

Re: [PHP-DEV] DateTimeZone silently falls back to UTC when providing seconds

2021-05-30 Thread Derick Rethans 
On 30 May 2021 22:45:12 BST, Benjamin Morel  wrote:
>Hi internals,
>
>An issue  was brought up
>on
>my date-time library, that boils down to the fact that DateTimeZone
>silently falls back to UTC when providing an offset with seconds:
>
>(new DatetimeZone('+01:45:30'))->getName(); // 00:00
>
>https://3v4l.org/9ZrK6
>
>If this is unsupported (this would make sense), should it throw an
>exception instead?
>
>Thank you for your time.
>
>⁠— Benjamin

I can't think of why this couldn't work. Duke a bug report please at 
bugs.php.net?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] DateTimeZone silently falls back to UTC when providing seconds

2021-05-30 Thread Benjamin Morel 
Hi internals,

An issue  was brought up on
my date-time library, that boils down to the fact that DateTimeZone
silently falls back to UTC when providing an offset with seconds:

(new DatetimeZone('+01:45:30'))->getName(); // 00:00

https://3v4l.org/9ZrK6

If this is unsupported (this would make sense), should it throw an
exception instead?

Thank you for your time.

⁠— Benjamin