AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks

[kolla]

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.

Code: [Select]

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

Code: [Select]

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:

Code: [Select]

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?

[guest11527]

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.

Yes, but when is this a problem? So, what is a script where you depend on date to act in a non-interactive way?

Ironically and adding to confusion, error messages are _not_ localised, but all plain english.

That *IS* confusing indeed, it should be consistent.

(What the use case is for jumping system-time back and forth day by day, I have no idea.. perhaps you know?)

To be consistent with the output of "date". Would it be more useful if date would be unable to read all date strings generated by the system? "List" gives you dates in this format (like "yesterday") and date uses the generic system date parser (part of the locale library) and of course, the date parser of the locale library can read whatever it produces. So it is just consistent. Not being able to parse its own output would certainly be a trigger for another complaint.

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).

The correct answer is then to localize the script. Anyhow, the AmigaDos date conversion functions cannot do that. They don't take a locale argument but use the system locale instead. You can change the system locale with the locale preferences, even in a script, though.


 

That is fine.

According to your request, no. The output would still be "gestern" instead of "yesterday" for the German locale.

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.

Unfortunately, that is a massive change of the locale system, and there are really much more important things than this stuff.

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.

I disagree. Every program that is not aware of the locale should use the right locale right away, and that is the locale selected by the user through the preferences. What would be the point of the preferences if the preferences had no impact on programs that do not have a preference themselves?

Sheesh! Again - to present time and date information in a contextual meaningful way from scripts.

Why is the output of a script running on a German system non-meaningful if it appears in German?

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:

Why does that cause any problems right now? Date is able to parse its own output, including that of list. It looks to me like a simple application of list format, date and backticks. Or execute.

And can you explain what "Setdate DH0:" actually does?

I need to check, it probably depends on the file system.

[kolla]

Moving on, on the topic of system time...

Default Amiga system time is default boot system time is 01-Jan-1978 00:00:00, if I recall correctly.

At boot, the Amiga will look for a an RTC (real time clock, typically battery backed), from what I understand this is what battclock.resource does.

If RTC is found, system time is set from that.

If RTC is _not_ fond, it will move on to look for timestamp on the filesystem of the boot device - it is unclear for me what timestamp is actually used, since "the experts" seems to disagree on what is used an what it is supposed to use, and it doesn't help that different filesystems treat these timestamp fields differently. What it looks like though, is that with FFS, the so called "Creation time" is used, and there are no tools in the OS that can alter this timestamp, other than SYS:System/Format. So this means that whenever you boot a system, system time will be the same as when the system partition was formatted, and all changes to files will be marked as done in the "future" on every boot. Not so satisfying.

There are work-arounds for this.

For example I used to have a small script running in the background that just use SetDate to update a SYS:.timestamp every 60 seconds, and on boot a script lists this timestamp file with LFORMAT that matches the input that C:Date accepts (this is so early that locales are not allowed to screw things up yet) and system time is hence set to the last time the sys:.timestamp file was updated. Of course it would help A LOT if C:Date could just have an option FROM, so all locale issues were forever gone for this _use case_. But writing to a disk filesystem every minute or so can be "dangerous", so a more safe option is to instead write to a warm-boot resident area in RAM. One can do this just by using OS tools, simply by making the smallest RAD disk possible, make sure it has lower bootpri than the system disk, and use a timestamp file there, and only write to a disk filesystem when turning off the machine entirely.

But this can be done better. On Aminet there is a tool TimeKeeper that does something clever - it reserves a small address space in RAM, makes it warm-boot resident, and then goes in the background as a "daemon" and keeps on writing the system timestamp to this address space every few seconds. On boot, it will then look for this address space and set system time accordingly. A boot typically takes a few seconds, depending on setup, so it also accepts an offset option, so one can add these seconds. If no timestamp is found, or it is scrambled, it also supports running a command line, which then can be used to set the system time from a different source, for example from timestamp file on a filesystem.

But all this are work-arounds, I very much think that AmigaOS 3 should by much better in dealing with system time on systems lacking RTC, and I certainly have ideas

[kolla]

Yes, but when is this a problem? So, what is a script where you depend on date to act in a non-interactive way?

Any system that lacks a functioning RTC, which I believe is vast majority of Amiga systems.

[kolla]

Why is the output of a script running on a German system non-meaningful if it appears in German?

Context.

Just because I have Norwegian locale (which Hyperion says I MUST use to stay license compliant, despite the cringing quality of the locales) does not mean I can not be in non-Norwegian contexts. We live in a reality where one cannot expect everything to be localised correctly, for many of us the correct locale does not even exist, and most of us are not mono-lingual. In SYS:Prefs/Locale can set up a prioritised list of languages, and this can lead to programs/scripts having mixed language output, which can be both entertaining and confusing.

[kolla]

Why does that cause any problems right now?

How do you list the timestamp of DH0: ?

In OS 3.2, what is the output of "List FLAT DH0:"?

[kolla]

The correct answer is then to localize the script.

I often do, but locales for my preferred native language do not even exist, so it becomes neo-norwenglish.

[guest11527]

In OS 3.2, what is the output of "List FLAT DH0:"?

For example like this. The directory name is "" (empty) and the time stamp is the time stamp of the root.

[guest11527]

If RTC is _not_ fond, it will move on to look for timestamp on the filesystem of the boot device - it is unclear for me what timestamp is actually used, since "the experts" seems to disagree on what is used an what it is supposed to use, and it doesn't help that different filesystems treat these timestamp fields differently.

The time stamp is taken from the creation date of the volume, which is in the root node. The creation date is not adjustable.
ACTION_SETDATE adjusts the modiifcation date of the node, and by that also that of the root node.

But all this are work-arounds, I very much think that AmigaOS 3 should by much better in dealing with system time on systems lacking RTC, and I certainly have ideas

Frankly, why do you care? You just said you don't accept the license, so don't want to buy the license, yet bought one.

[kolla]

In OS 3.2, what is the output of "List FLAT DH0:"?

For example like this. The directory name is "" (empty) and the time stamp is the time stamp of the root.

For example what? Nothing?

Code: [Select]

Directory "" is empty

[kolla]

The time stamp is taken from the creation date of the volume, which is in the root node. The creation date is not adjustable.

So the system will always boot to the same time, and all file changes will have modification timestamps in the future.

This is what should really be avoided, even when a system is without RTC, time should move _forward_ - not jump back to some rather random specific time on every reset.

ACTION_SETDATE adjusts the modiifcation date of the node, and by that also that of the root node.

If system time could be taken from modification time of the root node, it would help a lot already - then one can adjust "boot time" simply with "SetDate dh0:"

But all this are work-arounds, I very much think that AmigaOS 3 should by much better in dealing with system time on systems lacking RTC, and I certainly have ideas

Frankly, why do you care? You just said you don't accept the license, so don't want to buy the license, yet bought one.

That is an entirely different problem, which I just explained in a different thread - the license was not presented to me at point of sale - I very much expect the license to change in the future, perhaps even for OS 3.2.

Hyperion is, after all, run by a lawyer, and "legalese" is the only form of communication that works.

[kolla]

Moving on from the trolling attempts by the head OS developers... what can be done to improve the system time problem with Amiga systems that have no RTC?

First some goals:
* system time must as much as possible go _forwards_, even between reboots, warm and cold.
* there are situations when going backwards is unavoidable, in such cases, the "amount of time" going backwards should be kept as low as possible

My suggestion is inspired by TimeKeeper and getting timestamp for boot filesystem

One part is placed in kickstart (in existing or new module, why not systemd.. I mean System-Startup), if no functional RTC is found...

* check if a certain address space in chipram contains a valid timestamp, and set system time accordingly
* if no such valid timestmap is found, allocate an address space, it and make it warm-boot resident.
* Continue as today, take timestamp from boot filesystem, but rather "modified" timestamp rather than "created" timestamp.

Second part is "running code", it would be preferable if it too was in kickstart, but if not... something that "always runs", IPrefs is a candidate, and its job is simply to
* if dedicated address space in chipram exists, steadily and frequently update it with current timestamp.

This should keep system time going forward, and updating system time to a more "current" one is a matter of adjusting it manually or via NTP, GSM over serial port or whatever, and then just doing any kind of modification to boot volume - for example "SetDate DH0:"

[guest11527]

So the system will always boot to the same time, and all file changes will have modification timestamps in the future.

This is what should really be avoided, even when a system is without RTC, time should move _forward_ - not jump back to some rather random specific time on every reset.

You cannot avoid that. Leaving compatibility issues aside, touching a file only "bubbles up" one directory level (i.e. changes the change date of the containing directory), but it does not bubble up to the root level. That is, without doing a full tree search of the boot disk, you cannot prevent that a file has a change date in the future of the root directory.

If system time could be taken from modification time of the root node, it would help a lot already - then one can adjust "boot time" simply with "SetDate dh0:"

Though it is probably a bad idea to change this - besides, it would only be a change if the FFS is used to boot the system. For some bizarre reason, it is the boot file system that sets the system date.

What other file systems do is up to them - but there is no interface (DosPacket) to adjust the creation time of a file system, and inventing one would not improve the situation for any other file system.

[kolla]

So the system will always boot to the same time, and all file changes will have modification timestamps in the future.

This is what should really be avoided, even when a system is without RTC, time should move _forward_ - not jump back to some rather random specific time on every reset.

You cannot avoid that.

It can be avoided to a much larger degree than what is the case today.

Leaving compatibility issues aside

Can you think of any?

Is there any filesystem that Amiga can boot from, that does not have a root node to get system time from?

Do all filesystems that Amiga can boot from currently, all have a creation timestamp to get system time from?

touching a file only "bubbles up" one directory level (i.e. changes the change date of the containing directory), but it does not bubble up to the root level.

I know that, and nowhere did I imply that _any_ change to a filesystem would change the root node - that was not the point.

That is, without doing a full tree search of the boot disk, you cannot prevent that a file has a change date in the future of the root directory.

Very true - but again, that was not the point.

The point was to have the *boot system time* moving forward (albeit slowly), and to make it *easy* to bump up boot system time.

If system time could be taken from modification time of the root node, it would help a lot already - then one can adjust "boot time" simply with "SetDate dh0:"

Though it is probably a bad idea to change this

Because... anything specific you can think of?

 

besides, it would only be a change if the FFS is used to boot the system. For some bizarre reason, it is the boot file system that sets the system date.

I don't think it is so bizarre, really. Would it be less bizarre to always start in 1978-01-01 00:00:00?

What other file systems do is up to them - but there is no interface (DosPacket) to adjust the creation time of a file system, and inventing one would not improve the situation for any other file system.

Exactly - do all filesystems even have a creation timestamp?

The check for timestamp on the boot filesystem could have a prioritised list...
* check for the presence of a magic file in the root of the boot filesystem (I use :.timestamp myself)
* check for the presence of a modified timestamp on the root node of the boot filesystem
* check for the presence of a creation timestamp on the root node of the boot filesystem

[guest11527]

It can be avoided to a much larger degree than what is the case today.

I'm not sure in how far this is a "larger degree". In any case, the date is wrong, whatever mechanism you use to "invent" one from the file system. For those systems without an RTC, the date is probably not important in first case (low end machines, mostly gaming) and for those with an RTC, it does not matter. But I believe we shouldn't make the date seen by the system depending on the operating system.

Is there any filesystem that Amiga can boot from, that does not have a root node to get system time from?
Do all filesystems that Amiga can boot from currently, all have a creation timestamp to get system time from?

How should I know? I do not know whether or if SFS or PFS implement this mechanism.

I don't think it is so bizarre, really. Would it be less bizarre to always start in 1978-01-01 00:00:00?

The design is "upside down", really. Why is it the file system that has to do that? It is not the responsibility of a file system to care about the system time. It should be the responsibilty of the Os bootstrap code (aka "dos.library" pre-3.2, aka "system-startup" 3.2 and up) to do that and find a time source. And why take it only from the boot volume? This arrangement might have made sense at times there was only floppy boot. Realistically, it should be max(all volumes found) *if* a file system is even a source of a time stamp.

Then again, the time is made up anyway, so why bother about it? It's wrong in either case.

Exactly - do all filesystems even have a creation timestamp?

I do not know, not my business.

The check for timestamp on the boot filesystem could have a prioritised list...
* check for the presence of a magic file in the root of the boot filesystem (I use :.timestamp myself)
* check for the presence of a modified timestamp on the root node of the boot filesystem
* check for the presence of a creation timestamp on the root node of the boot filesystem

That's just another algorithm to make up a time, but to which amount is this better? And when? And why? It replaces one bogus time source by another bogus time source, and I don't see the benefits of this.

[kolla]

I don't see the benefits of this.

Well, I do - am I alone?

As you say, it is a matter of finding a time source at boot - a functional RTC is the best option, a user maintained timestamp (in memory, or file) is a good second, timestamp from root node of boot filesystem a bizarre third...

The most important is that system time should, as much possible, survive warm boots.