Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; _WikiDiffEngine has a deprecated constructor in /srv/website/_bw4/util/includes/diff.php on line 40
Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; WikiDiff has a deprecated constructor in /srv/website/_bw4/util/includes/diff.php on line 441
Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; WikiDiffFormatter has a deprecated constructor in /srv/website/_bw4/util/includes/diff.php on line 763
Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; WikiUnifiedDiffFormatter has a deprecated constructor in /srv/website/_bw4/util/includes/diff.php on line 931
Deprecated: assert(): Calling assert() with a string argument is deprecated in /srv/website/_bw4/util/includes/diff.php on line 335
Deprecated: assert(): Calling assert() with a string argument is deprecated in /srv/website/_bw4/util/includes/diff.php on line 355
Deprecated: assert(): Calling assert() with a string argument is deprecated in /srv/website/_bw4/util/includes/diff.php on line 355
Deprecated: assert(): Calling assert() with a string argument is deprecated in /srv/website/_bw4/util/includes/diff.php on line 335
Deprecated: assert(): Calling assert() with a string argument is deprecated in /srv/website/_bw4/util/includes/diff.php on line 355
Deprecated: assert(): Calling assert() with a string argument is deprecated in /srv/website/_bw4/util/includes/diff.php on line 355
Warning: Cannot modify header information - headers already sent by (output started at /srv/website/_bw4/liberty/content_history_inc.php:58) in /srv/website/_bw4/kernel/BitSystem.php on line 419
Warning: Cannot modify header information - headers already sent by (output started at /srv/website/_bw4/liberty/content_history_inc.php:58) in /srv/website/_bw4/themes/BitThemes.php on line 2109 - History of Time
This started as an email, but I realsied that I needed to expand on various point as I go, so this is the base version and I can add detail pages on various points.
+
This started as an email, but I realsied that I needed to expand on various point as I go, so this is the base version and I can add detail pages on various points. ((Ideal timestamp data)) identifies my ideal timestamp.
-
Many of the current standards do not always take real world situations into account, or even define basic limitations they have assumed. Blindly following one standard, such as the SQL ones misses the fact often that these were written before other standards that provide the essential data. Also at that time computers only talked in English so there was no need to worry about other alphabets. Today native English speakers and Christians are a minority and the majority expect their computers to work with their standards and at the very least allow them to enter data in their local language. So UTC8 tends to be a basic requirement of any data system and all the problems that introduces, yet the SQL standards are still essentially 'English' as is the case with most programming languages and international standards like the RFC system. PHP has even given up using anything but ASCII for code, although UTF8 variable names work most of the time if not documented.
+
Many of the current standards do not always take real world situations into account, or even define basic limitations they have assumed. Blindly following one standard, such as the SQL ones misses the fact often that these were written before other standards that provide the essential data. Also at that time computers only talked in English so there was no need to worry about other alphabets. Today native English speakers and Christians are a minority and the majority expect their computers to work with their standards and at the very least allow them to enter data in their local language. So UTC8 tends to be a basic requirement of any data system and all the problems that introduces, yet the SQL standards are still essentially 'English' as is the case with most programming languages and international standards like the RFC system. PHP has even given up using anything but ASCII for code, although UTF8 variable names work most of the time if not documented and is another can of worms. We supposedly have a soultion to international names, but does it work everywhere?
-
Currently the Firebird calendering system is very limited in what it can actually support. Many things date back to a time when it was easier to assume 1970 was the start of the modern world, so Firebird's adoption of 1AD on a Christian calendar was at least progress at that time, but just what calendar does it support 2.5 Language ref only says 01/01/0001 to 31/01/9999 and no mention if the gregorian gap is observed, so does the day count match the julian day. Just which country used which calendar is also variable upto as recently as 1922 for Greece.
+
Currently the Firebird calendering system is very limited in what it can actually support. Many things date back to a time when it was easier to assume 1970 was the start of the modern world, so Firebird's adoption of 1AD on a Christian calendar was at least progress at that time, but just what calendar does it support 2.5 Language ref only says 01/01/0001 to 31/01/9999 and no mention if the gregorian 100 year fix is observed, but having just tested things out, it looks like it is a gregorian calendar. Just which country used which calendar is variable upto as recently as 1922 for Greece so one can't have greek date 1900/02/29. So we can't use date offsets prior to the adoption of the gregorian calender. (https://www.timeanddate.com/calendar/gregorian-calendar.html)
Adding translations to support local users is something that databases are much better at than hard coded archives like those provided by ICU and other data sources. Although on line resources like geonames.org is now providing a fairly comprehensive cross reference for everything location wise. Providing a local timezone against a location is one of those facilities (you have to look up lat and lng first) but as with most of this material, there is no detail on what version of TZ is being used or more important these days if the location is in the same timezone as it was even last year! Also what needs to be confirmed is just what accuracy values are limited to. Being supplied as JSON data, the java manual is referenced, so Class TimeZone is used. This defines basic offsets in milliseconds, but only specifies hours and minutes in the definition. It does also highlight that legacy abbreviations are deprecated since they are not unique identifiers.