Getting Midnight in the UNIX Epoch from Perl

Many computer functions dealing with time are calculated in the number of seconds since the UNIX Epoch. I wanted to get midnight tomorrow in those Epoch seconds so that my Bible word Wordle clone Biblicle could say when the next word would be available. I couldn’t easily do the entire calculation on the client side in JavaScript, because when the next word is served varies: if the user is logged in, it is at midnight for the user’s specified time zone on FaithTree (which may or may not match their computer’s time zone), but if the user is not logged in, it will be at midnight Central Time (“US/Chicago”).

The calculation needed to be done on the backend on the server, which is written in Perl. This page had a suggestion how to get the number of seconds so far elapsed in the day, which could easily be modified to instead give me the number of seconds remaining. Problem: I want to calculate on the basis of the local time zone not UTC/GMT. Thankfully, using Perl’s DateTime object, that isn’t difficult:

use DateTime;
my $tomorrow = DateTime->now(time_zone => $timeZone);
my $secs = ((23 - $tomorrow->hour) * 3600) + ((59 - $tomorrow->min) * 60) + (59 - $tomorrow->sec);
$tomorrow->add( seconds => ($secs + 1) );
my $tomorrowStarts = $tomorrow->epoch;

With that little code snippet, $tomorrowStarts will return the first second of tomorrow located to $timeZone and relative to the Epoch.

Optimizing Little Hills, FaithTree and Open for Business

I’ve been deploying a lot of server optimization tricks to improve the performance of Little Hills, FaithTree and Open for Business these past months. They had all grown slow with the kludge of adding additional features and my once snappy homegrown content management system (also used here), SAFARI, was no longer snappy. That all threatened user frustration and, for that matter, lower rankings on Google, which pays attention to the performance of sites it refers people to.

I’ll blog about some of the other optimizations a different day, but one I’m rather pleased with is support for WebP. I’ll admit to ignoring it in no small part because Apple didn’t support it. I use primarily Apple Safari to browse the web, including pages served by my SAFARI (which I called that before Apple’s Safari was launched, so I’m being stubborn and keeping the name). However, WebP arrived on Safari with iOS 14 and MacOS Big Sur, so I revisited the format and found it could offer substantial savings in download size on many images. With support in every modern browser, I figured I’d implement support in SAFARI.

By support, I mean my goal was to be able to upload an image to the site and the software takes care of turning it into a WebP. SAFARI now does that, taking images of known types and running several layers of optimization. First, it tries to make a more efficient JPEG using ImageMagick’s PerlMagick module; once that is complete, it attempts to make a WebP version. It only keeps the optimized JPEG version if it is at least 20% smaller than the original. Likewise, it only keeps the WebP if it is that much smaller than the optimized JPEG. Since not everything older supports WebP, there’s no reason to mess with it, if a JPEG will do.

This is similar to what I later read described here. I want to implement more of Bernat’s optimizations in the future.

That’s great, I thought, but then I realized the next issue (which is described with a solution in Bernat’s piece, but I hadn’t found it yet at the time): if not every browser supports WebP, I have to be prepared to serve the JPEG still. The HTML5 <picture> element supports giving different image options and letting the browser installed, but my goal was not to require me (or anyone else someday posting to Little Hills’ site) to manually think through the process of describing alternatives. It also does nothing to take advantage of the automatically generated alternatives I previously created when it comes to existing pages.

The solution was complicated by another optimization I made. My long worn solution would be to come up with a series of mod_rewrite rules for my Apache server to analyze if the browser could handle WebP and then replaced the JPEG with a WebP if possible. However, I recently implemented an NGINX caching server to get its advantages over Apache, so I needed to figure out the NGINX way to do it. That turned out to be a bit confusing to me at first, but simple in practice.

Here’s the final bit of NGINX configuration magic used to reroute requests to WebP (or the optimized JPEG), as best suited. It finds any folder location under an images directory and then looks for an .optimized subdirectory. If it finds one, It looks for the WebP version if applicable and the optimized JPEG if the WebP version is unavailable or the browser does not support it.

location ~ ^(?<extra>.*?)(?<prefix>/images/(?:.*/)?)(?<rxfilename>.*)$ {
        expires 365d;
        add_header Pragma "public";
        add_header Cache-Control "public, no-transform";
        add_header Vary Accept;
        try_files $extra$prefix.optimized/$rxfilename.$webp_suffix $extra$prefix.optimized/$rxfilename.jpg $uri =404;
}

This has been working great for a couple of months now — I started writing this post back on July 7 and then got sidetracked — so if you’re looking to optimize your NGINX configuration, I definitely commend it to you.