zlacker

It's really cool that such standard exists, the worst thing about Pixel phones is stupid filenames of pictures and videos, not only it's not following this standard, but contains WRONG timestamp. For example, picture with name `PLX_20241101_115855.jpg` was taken at 12:58:55, not 11 as the name suggests, but also picture with name `PLX_20240913_191525.jpg` was taken at 19:15:25. A video on the other hand would have a timestamp offset -1, the offset changes depending on time of the year and it's different for pictures and videos. It's annoying af, because pictures and videos in the same folder will not be sorted chronologically by filename.

>>agilob+(OP)
Potentially daylight savings related? E.g. file names are in UTC, whereas local time obviously isn't

>>nasret+t
Yes, it's DST related. Now explain why DST offset is different for pictures and videos ;)

>>agilob+w
Well they need to be different in _some_ way, right :)? Why not use timestamp offset for this

>>agilob+(OP)
British? Sounds like it's recording UTC time in the file name, which is only correct during winter.

>>waltha+52
> British?

Nope, but it's a Pixel thing

>>agilob+(OP)
FWIW that is not a Pixel-specific issue. I encountered this on other cameras (IIRC Olympus and GoPro) as well. It's maddening.

The issue stems from the fact that images are written with proper EXIF time and timezone metadata while videos from the same camera might only store a timestamp field. Whether that's local time, UTC, or something else depends on the camera and how you configured it.

>>agilob+w
Programming employment-creation measure - to prevent them doing damage elsewhere by adding abstraction madhouses.

>>agilob+(OP)
A lot of the DCF standard is designed around the limitations of FAT file systems, e.g. filenames limited to 8+3 characters, directories limited to 9999 "items" (which I assume is to make sure that there won't be more than 65,536 files in a directory). As Pixel phones don't use FAT, Google probably doesn't feel bound by this standard. Their naming convention allows the phones to store all photos/videos in a single directory.

>>nasret+N
While this comment is a joke, it's tragicomically true as well.

Way too often have I encountered, or hacked in myself, such "business rules".

"Except for these seven transactions from before [random date/time] all transactions made between 01:00 and 01:15, with a round amount, are recurring payments to X. Can we not just use that instead of this data-migration that you've budgetted?" (not literal request, but close enough).

The danger -off course- lies in that this over time becomes actual business logic and that meaning is assigned to (meta)data that was never intended to carry such meaning.

The solution -I've found- starts with what DDD calls "ubiquitous language", where everyone (within a domain!) assigns the same meaning to the same things¹. And model the software around that, never the other way.

¹ So maybe there's a 150 year old rule that states that recurring transactions are those that happen between ...etc. etc. That this is actually a settled and used meaning within the domain experts/users/stakeholders. In that case - IMO - it's far better to lean into it rather than assign some is_recurring_for_x boolean or such that has no meaning in the domain.

>>waltha+52
2024-11-01 is in winter, 2024-09-13 is in summer. So the effect seems to be the opposite of what you say.

>>nasret+N
because the extensions are already different. jpg and mp4

>>catsma+aa1
Ok, fair point... I guess it's just that different teams were doing photo and video then

>>sampo+Qd
> 2024-11-01 is in winter, 2024-09-13 is in summer.

Not in... What's in the same time xone, but southern hemisphere; Sawth Effrika?