Welcome Guest, Not a member yet? Register   Sign In
Time diff NOT WORKING
#1
Bug 
(This post was last modified: 03-23-2024, 09:15 AM by pablo.hernandez.)

Hello,

PHP 8.2.12
CodeIgniter v 4.4.6

PHP Code:
use \CodeIgniter\I18n\Time;

$date1 = new Time("2024-03-31");
$date2 = new Time("2024-04-01");

echo 
$date1->difference($date2)->days;  // 0 !!!

// the native PHP classes work fine:

$date1 = new \DateTime("2024-03-31");
$date2 = new \DateTime("2024-04-01");

echo 
$date1->diff($date2)->format("%a");  // 1 

What is most strange: it actually works well for most other dates, I can't find why but this behavior makes this function useless...

many thanks for this excelent framework!
Reply
#2

(This post was last modified: 03-23-2024, 07:27 PM by kenjis.)

Cannot reproduce.
PHP 8.2.16
PHP 7.4.33

PHP Code:
$date1 = new Time("2024-03-31");
$date2 = new Time("2024-04-01");

echo 
$date1->difference($date2)->days;  // 1 
Reply
#3

(This post was last modified: 03-24-2024, 05:50 AM by pablo.hernandez.)

(03-24-2024, 02:07 AM)pablo.hernandez Wrote:
(03-23-2024, 07:25 PM)kenjis Wrote: Cannot reproduce.
PHP 8.2.16
PHP 7.4.33

PHP Code:
$date1 = new Time("2024-03-31");
$date2 = new Time("2024-04-01");

echo 
$date1->difference($date2)->days;  // 1 

Thank you for your reply; you are right, if I set up a brand new install of CI 4.4.6, no database setup, and put that code in the welcome_page view and IT WORKS (shows "1")

However, when I edit the app\Config\App.php file and change it for SPANISH LOCALE it STOPS WORKING for this example (shows "0")!

These are the lines changed in my App.php file:

PHP Code:
public string $defaultLocale 'es';
public array 
$supportedLocales = ['es'];
public 
string $appTimezone 'Europe/Madrid'

After some testing I've noticed that it is specifically the third line ($appTimezone) that is causing the error (if I change it back to UTC, the method throws "1" again!). It is a very strange behaviour because other date combinations do work with the modified App.php file, and according to the link included in that file just above the $appTimezone setting (https://www.php.net/manual/en/timezones.php), the string I'm using for the time zone should be valid.

The problem appears with any "Europe/X" city that I've tried (Amsterdam, Paris...)

Many thanks!
Reply
#4

Oh yes, Europe/Madrid makes the value 0!

PHP Code:
public string $appTimezone 'Europe/Madrid'
Reply
#5

(03-24-2024, 02:23 AM)pablo.hernandez Wrote: The problem is not just Madrid, it appears with any "Europe/X" city that I've tried (Amsterdam, Paris...)

In Europe, are 2024-03-31 and 2024-04-01 the same day!?
Reply
#6

(This post was last modified: 03-24-2024, 03:32 AM by pablo.hernandez.)

(03-24-2024, 02:38 AM)kenjis Wrote:
(03-24-2024, 02:23 AM)pablo.hernandez Wrote: The problem is not just Madrid, it appears with any "Europe/X" city that I've tried (Amsterdam, Paris...)

In Europe, are 2024-03-31 and 2024-04-01 the same day!?

Of course not! :-D  Mi guess is that this has to do with the damned daylight savings: European governments mess with the time since the oil crisis back in the 70s (1 hour back and forth on specific days of the year), theoretically in order to save some energy (?), and this year this change (2am becomes 3am) is due to happen precisely on 2024-03-31...
Reply
#7

I think this is because we have Daylight Saving Time (DST) in Europe, last week of march, and this year is on 2024-03-31
Reply
#8

Looking at the dates, my first thought was DST. DST in Europe originated in the First World War to aid in munitions manufacturing.

In Europe DST changes on the last Sunday in March and the last Sunday in October. It just so happens that this year the last Sunday is the 31st. The EU member states have voted to cease using DST but have yet to decide when this will happen - maybe on the last Sunday of October then they've an hour to decide if they like it and can switch it back again!
Reply
#9

It is recommended to always use UTC in your app, and use local timezone only when displaying date/time.

After all, the current implementation is correct, because the difference is 23 hours, less than 1 day.

testTime:  2024-03-31 22:00:00.000000 (UTC)
ourTime:    2024-03-30 23:00:00.000000 (UTC)
Reply
#10

(This post was last modified: 03-27-2024, 02:39 AM by pablo.hernandez.)

(03-24-2024, 04:11 PM)kenjis Wrote: It is recommended to always use UTC in your app, and use local timezone only when displaying date/time.

After all, the current implementation is correct, because the difference is 23 hours, less than 1 day.

testTime:  2024-03-31 22:00:00.000000 (UTC)
ourTime:    2024-03-30 23:00:00.000000 (UTC)

Well, IMHO this implementation is only "correct" if the unit of difference needed is hours (or smaller);  the case here is that our unfathomably wise politicians have decided that one specific day has 23 hours (and October 27th will have 25 hours to balance things out for the year). That is, they have redefined what a "day" is (Big Brother style :-). The CI method is CORRECTLY calculating 23 h for this particular interval, what is missing is that it should count as a FULL DAY

Any CI user interested in the day difference (which I guess is pretty common, e.g. in my project I just need to show the number of nights spent in a hotel given the arrival and departure dates) is going to be surprised to get a 0 (or a 2) when plugging in two consecutive calendar dates (in fact the glitch will bite you for every date interval that includes one of these 2 special days)... so I believe this should be patched, or at least mentioned in the documentation. 

Your suggestion to always use UTC project-wise, if my understanding is correct, would render useless some otherwise very convenient functions (https://codeigniter.com/user_guide/libraries/time.html) that are timezone-sensitive...

Many thanks
Reply




Theme © iAndrew 2016 - Forum software by © MyBB