zlacker

> Apple uses the ‘IMG_XXXX’ naming convention for all images and videos captured on iOS devices, where XXXX is a unique sequence number.

For what it's worth, Apple are just conforming to the JEITA/CIPA DCF standard: https://en.wikipedia.org/wiki/Design_rule_for_Camera_File_sy...

“DCF file names” specification sez… http://www.kronometric.org/phot/std/DC-009-2010_E.pdf#page=2...

“File names conforming to the following rules are called DCF file names.

• The file name is 8 characters (not including the file extension).

• The first four characters consist only of the upper-case alphanumeric characters shown in Table 1

• These are referred to as the DCF file name Free characters. They shall not contain two-byte characters or special codes.

• The four characters that follow are a number between "0001" and "9999". "0000" shall not be used. These four digits are referred to as File number.

• Files with the same file number stored in the same DCF directory are considered to be object component files as defined in 4.3.2.”

>>Lammy+(OP)
...and collisions between filenames that would happen because of the "wraparound" after 9999 images/videos are avoided by storing them in different directories.

>>Lammy+(OP)
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+bf
Potentially daylight savings related? E.g. file names are in UTC, whereas local time obviously isn't

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

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

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

>>waltha+gh
> British?

Nope, but it's a Pixel thing

>>agilob+bf
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+Hf
Programming employment-creation measure - to prevent them doing damage elsewhere by adding abstraction madhouses.

>>agilob+bf
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+Yf
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+gh
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+Yf
because the extensions are already different. jpg and mp4

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

>>sampo+1t
> 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?