I've tried in the past on windows and Mac to change the system time to 24h and when it comes to glancing at my clock it always just kinda bothers me to have to convert to 12h time for my brain to process (basically for the purpose of appointments). And yet, it never bothered me to use 24h time in filenames. Maybe I'm the problem.
Edit: changing the system clock to 24h solved the screenshot sorting issue for me, and seeing the 24h time bothers me so little that the fact that it solved literally any real problem makes it worth keeping it this way.
i donāt care about their preferences, i said that because they want 24h file names while refusing to set their system to use 24h. itās not a real problem.
That's what I do. 12h clocks, 24h file names. Again, bitching about other people having preferences that don't line up with yours. It's a re-programmable computer. Trying to tell me that's impossible for Apple engineers to do? Defending a design oversight that's easy to fix?
dawg, itās a simple choice. the option to switch it is there. it is ridiculous to account for a user wanting to use multiple separate time systems.
regardless, this post is complaining that the file names arenāt 24h. they can be 24h, OP is just choosing to not enable that option. itās really as simple as that.
Nah the complaint is that the filenames aren't by default sorted in chronological order because of the filename formatting.
Also now that I'm aware of the fix, I changed it. If changing my system clock to 24h didn't solve any problems I wouldn't care to do it. But since it does solve a problem I have, I've changed it. I'm practical that way.
But also of note: My date is set to American rendering (month-day-year) because of familiarity but they did year-month-day on these filenames. Probably because someone thought far enough ahead on that detail to realize that filenames with American date format would be all out of order and really confusing.
The sorting issue is particularly galling because all of my time settings were default, and this is the region where the company that made this software is HQ'd. So apparently nobody who made this feature cared about the sorting problem.
well, i honestly imagine if they just defaulted to 24h time in filenames theyād get plenty of people upset about āmilitary timeā. the date is very interesting though
OP doesn't like it, because the solution requires changing their preferred clock view. It's not that hard to understand bro. I feel like you're being purposefully obtuse.
This is something a MacOS engineer could probably fix in 1-2 hours.
Ok, or we could talk about this. 24h time is stupid and is only applicable to situations like this. 12h time is standard in the US, the UK, Australia, Canada, New Zealand, Mexico, even fucking India. That's BILLIONS of people, and you're telling them they're all wrong because you can't understand having preferences different from yours.
It doesn't even line up with standard clocks.
Imagine telling all those people you won't do a simple software update because you "it doesn't affect me." You're an inconsiderate narcissist who doesn't care about anyone but yourself. Happy now?
This is something a MacOS engineer could probably fix in 1-2 hours.
I can assure you, adding more complexity to an already very complex system is usually not trivial, even if it seems trivial at a first glance. You then have to take into account a lot of unexpected interactions with other parts of the system.
Besides, this is only one niche requirement. If you're gonna account to every niche requirement that every single user might slightly desire, soon enough you will be flooded in settings and edge cases entangling in a hell that will prevent you from adding or fixing anything.
Not a niche requirement. Billions of people across the globe use 12h time. And, it's how a standard clock works.
Edit: I can tell you as a programmer, nobody is writing their own time & date functions. Those already exist, and for good reason. And Mac OS already has them installed by default, as evidenced by it being able to switch between the two time formats already. The heavy lifting is already done, the only thing a Mac OS engineer would need to do is add another variable to account for it, and do some minor UI tweaks.
In a self-consistent system sure it doesn't bother me, but when my wife walks in and asks me how long until the evening plans, if my handy clocks are different than the calendar, I have to convert then do the math, and alternatively if my calendar is 24h and hers isn't, there's too much potential for miscommunication and frustration.
It's not the negligible thing people seem to make it out to be.
Using a period to separate hour/minute/second is a bad idea. Some of us actually care about sub-seconds (e.g. scientific timestamp), and that is the only legitimate use of the decimal point in time formats. Example: 12:34:56.789 (which is 789 milliseconds after 12:34:56).
It still won't sort correctly. Here is chronological order: 12A, 01A, 02A, 03A, 04A, 05A, 06A, 07A, 08A, 09A, 10A, 11A.
And here is text sort order: 01A, 02A, 03A, 04A, 05A, 06A, 07A, 08A, 09A, 10A, 11A, 12A.
(And for previous reference, here is the text sort order without a leading zero: 1A, 10A, 11A, 12A, 2A, 3A, 4A, 5A, 6A, 7A, 8A, 9A; 1P, 10P, 11P, 12P, 2P, ..., 9P.)
(Ironically, Japan's weird 12-hour clock where "12" is labeled as "0" (like 0:00 am, 0:00 pm) would sort correctly if a leading zero was included. But no one else in the world seems to use this notation, so it will confuse anyone else who is accustomed to 12-hour time.)
Japan has a logical order while the anglophone has a weird system. It's like someone using MDY, calling ISO weird for using YMD.
In Japan, AM 0 is the start of the day and AM 12 is noon. PM 0 is also noon and PM 12 is the end of the day. This can be seen in things like "AM 0-12" and "AM 0 - AM 12".
Mine's that way, yeah. And while it may not be perfectly compliant with the standard, it will at least always sort properly: since the "at" is in every screenshot, it's effectively irrelevant. For example, one currently sitting on my desktop at home is "Screen Shot 2022-01-21 at 16.06.12.png".
Finder correctly sorts numbers, i. e. in this case it put the 4 before the 12. The problem of course is the 12-hour clock, in which 4 PM comes after 12 AM.
Sadly, the only customizable part is the word Screenshot. Dots are used because macOS sometimes has issues with : in file names. Iām surprised thereās no way to get a leading zero but the bigger problem is that the ā at ā canāt be removed. It is localized per language but I donāt know if itās possible to modify the localization
As others have pointed out, you can change your time format system setting. Also, the colon was used as the directory separator on classic Mac OS. When Mac OS X was built, the decision was made to support the slash in filenames ā since this is the directory separator in UNIX, slashes are internally represented with colons.
Switch to 24-hr time in System Settings, it solves the problem.
I've tried in the past on windows and Mac to change the system time to 24h and when it comes to glancing at my clock it always just kinda bothers me to have to convert to 12h time for my brain to process (basically for the purpose of appointments). And yet, it never bothered me to use 24h time in filenames. Maybe I'm the problem.
Edit: changing the system clock to 24h solved the screenshot sorting issue for me, and seeing the 24h time bothers me so little that the fact that it solved literally any real problem makes it worth keeping it this way.
American citizen moment
fr bro can't subtract 12 š
you are indeed the problem
Reddit when people have preferences that aren't theirs
i donāt care about their preferences, i said that because they want 24h file names while refusing to set their system to use 24h. itās not a real problem.
That's what I do. 12h clocks, 24h file names. Again, bitching about other people having preferences that don't line up with yours. It's a re-programmable computer. Trying to tell me that's impossible for Apple engineers to do? Defending a design oversight that's easy to fix?
dawg, itās a simple choice. the option to switch it is there. it is ridiculous to account for a user wanting to use multiple separate time systems.
regardless, this post is complaining that the file names arenāt 24h. they can be 24h, OP is just choosing to not enable that option. itās really as simple as that.
Nah the complaint is that the filenames aren't by default sorted in chronological order because of the filename formatting.
Also now that I'm aware of the fix, I changed it. If changing my system clock to 24h didn't solve any problems I wouldn't care to do it. But since it does solve a problem I have, I've changed it. I'm practical that way.
But also of note: My date is set to American rendering (month-day-year) because of familiarity but they did year-month-day on these filenames. Probably because someone thought far enough ahead on that detail to realize that filenames with American date format would be all out of order and really confusing.
The sorting issue is particularly galling because all of my time settings were default, and this is the region where the company that made this software is HQ'd. So apparently nobody who made this feature cared about the sorting problem.
well, i honestly imagine if they just defaulted to 24h time in filenames theyād get plenty of people upset about āmilitary timeā. the date is very interesting though
OP doesn't like it, because the solution requires changing their preferred clock view. It's not that hard to understand bro. I feel like you're being purposefully obtuse.
This is something a MacOS engineer could probably fix in 1-2 hours.
or just use 24h because itās better lol. this entire sub is literally built around a specific preference
Ok, or we could talk about this. 24h time is stupid and is only applicable to situations like this. 12h time is standard in the US, the UK, Australia, Canada, New Zealand, Mexico, even fucking India. That's BILLIONS of people, and you're telling them they're all wrong because you can't understand having preferences different from yours.
It doesn't even line up with standard clocks.
Imagine telling all those people you won't do a simple software update because you "it doesn't affect me." You're an inconsiderate narcissist who doesn't care about anyone but yourself. Happy now?
I can assure you, adding more complexity to an already very complex system is usually not trivial, even if it seems trivial at a first glance. You then have to take into account a lot of unexpected interactions with other parts of the system.
Besides, this is only one niche requirement. If you're gonna account to every niche requirement that every single user might slightly desire, soon enough you will be flooded in settings and edge cases entangling in a hell that will prevent you from adding or fixing anything.
Not a niche requirement. Billions of people across the globe use 12h time. And, it's how a standard clock works.
Edit: I can tell you as a programmer, nobody is writing their own time & date functions. Those already exist, and for good reason. And Mac OS already has them installed by default, as evidenced by it being able to switch between the two time formats already. The heavy lifting is already done, the only thing a Mac OS engineer would need to do is add another variable to account for it, and do some minor UI tweaks.
If you suffer the bother little, it will become second nature. .
Welcome to the path.
It's literally so easy to convert to 12-hour time. Just subtract 12 from the hour??
In a self-consistent system sure it doesn't bother me, but when my wife walks in and asks me how long until the evening plans, if my handy clocks are different than the calendar, I have to convert then do the math, and alternatively if my calendar is 24h and hers isn't, there's too much potential for miscommunication and frustration.
It's not the negligible thing people seem to make it out to be.
Here's a tip: don't subtract
15 o'clock is 15 o'clock
Even then, it should really be 04.00.00, not 4.00.00.
Period character '.' is NOT compliant with ISO 8601 as hour/minute/second separator
The best we could do while remaining compliant is
040000, since we can't do04:00:00because we cannot have colon in file namesUsing a period to separate hour/minute/second is a bad idea. Some of us actually care about sub-seconds (e.g. scientific timestamp), and that is the only legitimate use of the decimal point in time formats. Example: 12:34:56.789 (which is 789 milliseconds after 12:34:56).
What is so precise that you are measuring using screenshots?
12.34.56,789 ;)
Well ISO 80000-1 prefers decimal comma
Why can't we have the file names in 24h, and the clock in 12h? This is a kludge.
Or just put AM and PM before the actual time
There's a logic to that but that makes me nauseous
But text sort order won't match chronological order, because "12 AM, 1 AM, 2 AM, ..., 11 AM, 12 PM, 1 PM, ..., 11 PM" are not in text sort order.
Yeah true, IF you need to use AM and PM you need leading zeroes.
It still won't sort correctly. Here is chronological order: 12A, 01A, 02A, 03A, 04A, 05A, 06A, 07A, 08A, 09A, 10A, 11A.
And here is text sort order: 01A, 02A, 03A, 04A, 05A, 06A, 07A, 08A, 09A, 10A, 11A, 12A.
(And for previous reference, here is the text sort order without a leading zero: 1A, 10A, 11A, 12A, 2A, 3A, 4A, 5A, 6A, 7A, 8A, 9A; 1P, 10P, 11P, 12P, 2P, ..., 9P.)
(Ironically, Japan's weird 12-hour clock where "12" is labeled as "0" (like 0:00 am, 0:00 pm) would sort correctly if a leading zero was included. But no one else in the world seems to use this notation, so it will confuse anyone else who is accustomed to 12-hour time.)
True, forgot that 12 come before 01 etc.
I'm so used to the 24 h clock that I forgot about that
Japan has a logical order while the anglophone has a weird system. It's like someone using MDY, calling ISO weird for using YMD.
In Japan, AM 0 is the start of the day and AM 12 is noon. PM 0 is also noon and PM 12 is the end of the day. This can be seen in things like "AM 0-12" and "AM 0 - AM 12".
can you set a 24 hour system clock on the Mac in settings and make it save with the right format?
Mine's that way, yeah. And while it may not be perfectly compliant with the standard, it will at least always sort properly: since the "at" is in every screenshot, it's effectively irrelevant. For example, one currently sitting on my desktop at home is "Screen Shot 2022-01-21 at 16.06.12.png".
Itās not perfectly compliant with date-time, but it is compliant with date and, separately, with time.
Period character '.' is NOT compliant with ISO 8601 as hour/minute/second separator
My bad, I missed that part.
Yep that did it for me! Thanks. That actually officially makes it worth it for the system clock to be in 24h time.
I just have a script (previously a Launch Agent) watching for new screenshots and rename them reasonably š
Good idea! I have one setup for converting HEIC to JPEG for ease of sharing, didn't think of automated renames for this purpose
Good idea! I have one setup for converting HEIC to JPEG for ease of sharing, didn't think of automated renames for this purpose
First, select ISO8601 as your time format.
And while Screenshot isn't ideal, it still works.
You can't just omit the leading zero like that
For real though! That's the part that initially annoyed me and then I realized the sorting issue
Finder correctly sorts numbers, i. e. in this case it put the 4 before the 12. The problem of course is the 12-hour clock, in which 4 PM comes after 12 AM.
Sadly, the only customizable part is the word Screenshot. Dots are used because macOS sometimes has issues with : in file names. Iām surprised thereās no way to get a leading zero but the bigger problem is that the ā at ā canāt be removed. It is localized per language but I donāt know if itās possible to modify the localization
As others have pointed out, you can change your time format system setting. Also, the colon was used as the directory separator on classic Mac OS. When Mac OS X was built, the decision was made to support the slash in filenames ā since this is the directory separator in UNIX, slashes are internally represented with colons.
....... what.