I find it rather annoying that C:Date *requires* different input, depending on locale settings...
It requires as input the same format it prints as output.
It means that one cannot use the same input on two systems with different locale, as the TLA for months are different in different languages - it would be convenient if it at least also supported just plain English input.
Ironically and adding to confusion, error messages are _not_ localised, but all plain english.
4.Kladd:> date
Lørdag 14-Des-19 10:40:13
4.Kladd:> date yesterday
***Bad args
- use DD-MMM-YY or <dayname> or yesterday etc. to set date
HH:MM:SS OR HH:MM to set time
4.Kladd:> date "i går"
4.Kladd:> date
Fredag 13-Des-19 10:41:07
4.Kladd:>
(What the use case is for jumping system-time back and forth day by day, I have no idea.. perhaps you know?)
It would be very useful if ...
* had an LFORMAT option for printing custom date strings, which implies not changing the system time
C:Date LFORMAT "The year is %Y, the month is %M, and the date is %D, time is currently %T"
C:Date tomorrow LFORMAT "Tomorrow is %M %D, %Y"
What is the use case for that? That is, what is the situation you run into trouble with the current way how "date" looks like?
Trouble? I just gave two example - it is *useful* for presenting time/date information in a way that is independent of locales - it looks funny when dates are presented in norwegian in a script that otherwise prints out english (and it doesn't help that the Norwegian locales are flawed as well).
Note well that we can certainly add something like Lformat for "date" in principle, but the output would still be locale dependent because the strings into which these formatting options expand into depend on the locale.
That is fine.
Ideally, IMO, C:Date (and the other CLI tools) should primarily use $LANGUAGE and secondly use locale settings - it should be possible to easily override system wide locale setting with a shell-local/script-local variable. Yes, I know that $LANGUAGE is a legacy BCPL/TRIPOS variable. Any program that is not localised in itself, should never require localised input - the C:Date error messages are in English, for me they should have been in Norwegian - I only found out that I must use "I går" and "I morgen" (yes, two words, with quotes around) by chance.
* could use timestamp of resources like files, directories, filesystems as reference, instead of system time, also neat for _setting_ the system time from a reference file or filesystem:
C:Date FROM S:Startup-Sequence LFORMAT "File is from %T at %D/%M, %Y"
C:Date FROM DH0:
Again, what is the use case?
Sheesh! Again - to present time and date information in a contextual meaningful way from scripts.
I understand that at some point you want to carry over a date from one file to another. SetDate FROM can do that for you. Why date?
Why do you want to carry over date from one file to another? What is the use case for that?
In my above example, the idea is that "Date FROM DH0:" sets system time from the timestamp of DH0: - useful when DH0: is not initial boot device, for example when booting from RAD:
And can you explain what "Setdate DH0:" actually does?