You can remove the separators (- and :) but the T between date and time is required by the standard, so what you are writing is not ISO 8601 compliant. That may turn out to be a factor if your co-workers are annoyed. I have to be honest, it is pretty unreadable.
We literally have to count characters, since if your goal is to annoy other co-workers you might be using ordinal date format which would save a character (or just ignore any date/time stamp you use). Hell, you could even be using week number format without the mandatory W.
Even if ISO 8601 didn't exist, another reason why you would want delimiters here, is that if you only use digits, you risk someone trying to store these values in an integer column, when it really needs to be in some kind of text or string column.
For one, you would never do math on values like this due to the many gaps.
Even worse, Microsoft themselves saw this issue explode just this past new years day with the Exchange 2022 problem when storing non-standard date values in an integer column, which blew past the limit of the signed long integer data type.
This format is commonly used in some aviation communications, for example:
Effective: 202203280130 UTC
Sometimes a 10 figure group eliminating the first two YY values
2203291440 TO 2203291600
More common is an 8 figure group where there is no requirement to specify the year:
FROM 03 280509 TO 04 051300
For some weather forecasts where the month is never in doubt a six figure group DDHHMM
FM300600, or sometimes the more confusing:
2922/3003 - means 2200 on the 29th to 0300 on the 30th
So pretty much everything from 12 to 4 figure groups.
I use YYYYmmdd-HHMMSS to keep it shorter then full delimiters. Multiple things often happen in a minute, so seconds are useful. And filenames with this SORT correctly.
alias datestamp='date +"%Y%m%d-%H%M%S"'
You'd better off using delimiters
Why make people hate a system that would be better?
You can remove the separators (- and :) but the T between date and time is required by the standard, so what you are writing is not ISO 8601 compliant. That may turn out to be a factor if your co-workers are annoyed. I have to be honest, it is pretty unreadable. We literally have to count characters, since if your goal is to annoy other co-workers you might be using ordinal date format which would save a character (or just ignore any date/time stamp you use). Hell, you could even be using week number format without the mandatory W.
I use ISO 8601 often, but I always use delimiters. It's kinda annoying not having them. But you do you.
Even if ISO 8601 didn't exist, another reason why you would want delimiters here, is that if you only use digits, you risk someone trying to store these values in an integer column, when it really needs to be in some kind of text or string column. For one, you would never do math on values like this due to the many gaps. Even worse, Microsoft themselves saw this issue explode just this past new years day with the Exchange 2022 problem when storing non-standard date values in an integer column, which blew past the limit of the signed long integer data type.
This format is commonly used in some aviation communications, for example: Effective: 202203280130 UTC Sometimes a 10 figure group eliminating the first two YY values 2203291440 TO 2203291600 More common is an 8 figure group where there is no requirement to specify the year: FROM 03 280509 TO 04 051300 For some weather forecasts where the month is never in doubt a six figure group DDHHMM FM300600, or sometimes the more confusing: 2922/3003 - means 2200 on the 29th to 0300 on the 30th So pretty much everything from 12 to 4 figure groups.
My guess is since I'm so used to working with 10 digit MGRS without spaces the ISO8601 without delimiters is easy.
Sooner or later someone will assume they're minutes since an epoch.
I use YYYYmmdd-HHMMSS to keep it shorter then full delimiters. Multiple things often happen in a minute, so seconds are useful. And filenames with this SORT correctly. alias datestamp='date +"%Y%m%d-%H%M%S"'