There are plenty of times in my career when I’ve stored a boolean and later wished I’d had a timestamp. There are zero times when I’ve stored a timestamp and regretted that decision.
Hear hear! Over the years I’ve come to include 9 meta fields for most of the tables I create: added_at, added_by, added_ip, edited_at, edited_by, edited_ip, deleted_at, deleted_by, and deleted_ip. Handy for whenever you receive a phone call saying that a record has disappeared, allowing you to pinpoint it to a user and a specific timestamp.
Anyone who has worked with dates and time in JavaScript knows how broken the built-in Date is. In the near future we’ll be able to use Temporal instead, an ECMAScript feature currently at Stage-3
Stage-3 is the Candidate Stage where the feature is considered complete and only critical changes will happen based on implementation experience. If all goes well the proposal will advance to Stage 4 without any changes, after which it will to become part of the ECMAScript Specification.
Nathan Sebhastian has a good overview on how it compares to Date, along with some practical examples.
The new Temporal API proposal is designed to solve the problems with the Date API. It brings the following fixes to JavaScript date/time manipulation:
Creating and dealing only with immutable Temporal objects
Straightforward API for date and time computations
Part of a PHP project I’m working contains a list of sites/buildings. For each site/building we monitor some data, for example its energy usage.
We decided that we wanted to generate a daily/weekly/monthly reports of the data, by aggregating the datapoints. As our sites/buildings are spread across the globe – and thus timezones – we can’t simply select data between 00:00:00 UTC and 23:59:59 UTC but have to use its geographical location’s “day window” to do our calculations.
Unfortunately we don’t didn’t store the timezone for a site/building, but since we do keep track of its geographical location – using a WGS84 latitude-longitude pair – it should be possible to derive its timezone, right?
// Timezone for one NY coordinate
echo get_nearest_timezone(40.772222,-74.164581);
// ~> America/New_York
// Timezone for one Belgian coordinate
echo get_nearest_timezone(51.0162167, 3.7338451);
// ~> Europe/Brussels
// More faster and accurate if you can pass the country code
echo get_nearest_timezone(40.772222, -74.164581, 'US');
// ~> America/New_York
With this timezone identifier now being available, we can include it in our queries and generate our daily/weekly/monthly reports 🙂
🍻 Here’s to copying-and-pasting from StackOverflow!
Measuring time is a complicated thing. Computers, banks, and stock markets in Denmark all use UTC, the international standard: but according to the law, they shouldn’t.
In case you want to impress your family over Christmas’/New Year’s Dinner:
A so-called calendrical savant (or calendar savant) is someone who despite their intellectual disability (typically autism) can name the day of the week of a given date, or visa versa in a few seconds or even a tenth of a second (Kennedy & Squire, 2007).
While extremely impressive to behold, calendar calculations are actually very simple to perform and can be learned in less than 30 minutes. This short article will teach you how.
Freek has created spatie/test-time, a package to easily freeze/rewind/advance time in PHP.
Imagine you’re building that your app can notify your user, but you don’t want to send more than one notification in a timeframe of five seconds. How are you going to test the time aspect? Do you have to create a test that takes five minutes?
Luckily the answer is “no”. If you’re using the popular Carbon library, you can set the value that the library considers “now”
The package provides a few convenience methods around Carbon’s setTestNow method:
// time will not progress anymore
TestTime::freeze();
// Advance one minute
TestTime::addMinute();
// Rewind 5 hours
TestTime::subHours(5);
One of the (Symfony based) PHP projects I’m working on contains a form which allows the user to generate video clips from CCTV footage. To do this the user can enter a start and stop DateTime. For this to work the submitted input data is then checked: both start and stop must be dates, and the stop date must be set to a point in time after the start date.
Symfony’s DateTime Constraint can make sure both entries are DateTime instances. To check whether that the end date is after the begin date, one can use the Callback Constraint. Injected into that callback is a ExecutionContextInterface by which you can access the form, and thus other form params.
Here’s an example with the inputs start and stop:
use Symfony\Component\Validator\Constraints;
use Symfony\Component\Validator\Context\ExecutionContextInterface;
// …
$builder
->add('start', 'datetime',
'constraints' => [
new Constraints\NotBlank(),
new Constraints\DateTime(),
],
])
->add('stop', 'datetime', [
'constraints' => [
new Constraints\NotBlank(),
new Constraints\DateTime(),
new Constraints\Callback(function($object, ExecutionContextInterface $context) {
$start = $context->getRoot()->getData()['start'];
$stop = $object;
if (is_a($start, \DateTime::class) && is_a($stop, \DateTime::class)) {
if ($stop->format('U') - $start->format('U') < 0) {
$context
->buildViolation('Stop must be after start')
->addViolation();
}
}
}),
],
]);
If you want to have a minimum duration between both start and stop, you can change the number 0 in the snippet above to any number of seconds.
Did this help you out? Like what you see? Thank me with a coffee.
I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!
$carbon = new Carbon('first day of next week');
if ($carbon->isWeekend()) {
echo 'Party!';
}
echo $carbon->addYear()->diffForHumans(); // 'in 1 year'
Carbon is just a class which is designed to be used instead of DateTime. Due to extending DateTime, all DateTime methods are available to users of Carbon. Additionally, it implements a __toString method, allowing users to put it in place of string representations of date and time as well.
