zlacker

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

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

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

>>nasret+XI
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.