And the fact that you need to create a wrapper means that some programmers won’t bother to do it, or won’t know they need to do it. The default case handling timezones correctly will reduce potential errors.
And the fact that you need to create a wrapper means that some programmers won’t bother to do it, or won’t know they need to do it. The default case handling timezones correctly will reduce potential errors.
You should look at it, they say the implement RFC 9556 timestamps, which include tz info. In my experience it IS useful in real use, because a fixed offset timestamp can lose a bit of information.
For example, if you have a timestamp and want to add a few months to it, for example for a reminder, you will get a timestamp at the same time in the same offset. In many cases that will be wrong, because of things like daylight savings time, which change the offset of the timezone. You will get a timestamp an hour before or after the moment you intended, and it will be in the “wrong” offset in that timezone in that time of year. With timezone aware timestamps, they are aware that the offset will change, and will be able to give a timestamp in the future at the correct time and offset.
In this section, wouldn’t be more realistic for
chrono
users to use timezone info around the wire instead of on the wire, rather than usingLocal
+FixedOffset
?
They do say that the difference is that chrono
users would need to keep out-of-band timezone information in addition to the datetime, whereas Jiff
does it in-band.
I have a Surface Go 1 with 8 GB RAM running Aurora-DX, which includes the linux-surface kernel. It works great, and I find that modern KDE works quite well with touch, even though I mostly use it with the type cover attached. I only use the surface connect port for charging, but I do use the single usb-c port with a usb-c hib, and it works well. The Fedora atomic distros work great on little machines like that.
Edit: I’d add that Bluefin is the same with Gnome.
Probably wifi, I dont think Moonlight Embedded uses much ram. I also get the undervoltage warning nearly constantly, since the a+ is powered by the usb port of a projector. Maybe that also affects things.
To add more details, I use Sunshine as the server, and stream 1080p, in HEVC for the pi 4 and 5, and h264 for the 3 A+.
I use Moonlight Qt on a raspberry pi 5, and used it on a raspberry pi 4 before that. Both connected via ethernet, streaming at 150 mbps. It works very well, feels like being at the computer. It feels like there is next to no delay, and moonlight reports around 5 ms.
Somewhere else I use a raspberry pi 3 A+ with Moonlight Embedded, connected via Wi-Fi, and it works pretty well, but I can notice the delay a bit more. Still able to stream at 40 mbps.
I have the 128 GB storage 8 GB RAM, it’s still very usable. I often get annoyed with the small SSD, I’d assume 64 GB is way too small. Also if I remember correctly the 64 GB version has much slower eMMC storage, while the 128 GB and up have a real SSD.
I installed it successfully on a 512 MB machine the other day, with LXQT. Didn’t run very well though.
Btrfs snapshots are great! All my filesystem is Btrfs, with subvolumes for root, home and var.
I’m using the Fedora immutable distros on many computers, it’s great to be able to boot into a previous version of the system if issues arise. Not that issues arise, since most packages are installed as Flatpaks, in a toolbox or in a container. Makes the systems nearly unbrickable.
I use Fedora IoT on one of mine, for the immutable OS and container focus.
Yep, four of them, hence the “Q”.
Well it’s not called easyware