Date Representation, Julian Day, dimensional numbers
Here are John Randall's notes from 4/12/05 on how to represent and manipulate dates comprehensively and uniformly. Also, there's a suggestion from Neville Holmes on using dimensional, as opposed to the usual, dimensionless, numbers to better represent dates.
1. Julian day: a single integer.
2. YMD: a list of <year> <month> <day>.
3. String representing a date.
We propose two verbs
jday: rank 1 1 1
jdate: rank _ 1 0
These are obverses of each other. The idea is that jday operating on a date gives a Julian day, and that jdate operating on a Julian day gives a date.
jday <y m d>--><D>
Rank is 1, so we can convert a list of dates to days.
jdate <D>--><y m d>
Rank is _, so we can convert a list of days to dates.
For dates represented as strings, we need to specify the format. This is supplied as the left argument.
<format string> jday <date string>--><D>
Left rank 1, right rank 1.
<format string> jdate <D>--><date string>
Left rank 1, right rank 0 (or possibly _, since we are most likely to be applying a fixed format string to a list of dates).
Unix DATE Command Manual Page
DATE(1) User Commands DATE(1) NAME date - print or set the system date and time SYNOPSIS date [OPTION]... [+FORMAT] date [-u|--utc|--universal] [MMDDhhmm[[CC]YY][.ss]] DESCRIPTION Display the current time in the given FORMAT, or set the system date. -d, --date=STRING display time described by STRING, not 'now' -f, --file=DATEFILE like --date once for each line of DATEFILE -r, --reference=FILE display the last modification time of FILE -R, --rfc-2822 output date and time in RFC 2822 format --rfc-3339=TIMESPEC output date and time in RFC 3339 format. TIMESPEC='date', 'sec- onds', or 'ns' for date and time to the indicated precision. -s, --set=STRING set time described by STRING -u, --utc, --universal print or set Coordinated Universal Time --help display this help and exit --version output version information and exit FORMAT controls the output. The only valid option for the second form specifies Coordinated Universal Time. Interpreted sequences are: %% a literal % %a locale's abbreviated weekday name (e.g., Sun) %A locale's full weekday name (e.g., Sunday) %b locale's abbreviated month name (e.g., Jan) %B locale's full month name (e.g., January) %c locale's date and time (e.g., Thu Mar 3 23:05:25 2005) %C century; like %Y, except omit last two digits (e.g., 21) %d day of month (e.g, 01) %D date; same as %m/%d/%y %e day of month, space padded; same as %_d %F full date; same as %Y-%m-%d %g last two digits of year of ISO week number (see %G) %G year of ISO week number (see %V); normally useful only with %V %h same as %b %H hour (00..23) %I hour (01..12) %j day of year (001..366) %k hour ( 0..23) %l hour ( 1..12) %m month (01..12) %M minute (00..59) %n a newline %N nanoseconds (000000000..999999999) %p locale's equivalent of either AM or PM; blank if not known %P like %p, but lower case %r locale's 12-hour clock time (e.g., 11:11:04 PM) %R 24-hour hour and minute; same as %H:%M %s seconds since 1970-01-01 00:00:00 UTC %S second (00..60) %t a tab %T time; same as %H:%M:%S %u day of week (1..7); 1 is Monday %U week number of year, with Sunday as first day of week (00..53) %V ISO week number, with Monday as first day of week (01..53) %w day of week (0..6); 0 is Sunday %W week number of year, with Monday as first day of week (00..53) %x locale's date representation (e.g., 12/31/99) %X locale's time representation (e.g., 23:13:48) %y last two digits of year (00..99) %Y year %z +hhmm numeric timezone (e.g., -0400) %:z +hh:mm numeric timezone (e.g., -04:00) %::z +hh:mm:ss numeric time zone (e.g., -04:00:00) %:::z numeric time zone with : to necessary precision (e.g., -04, +05:30) %Z alphabetic time zone abbreviation (e.g., EDT) By default, date pads numeric fields with zeroes. The following optional flags may follow '%': - (hyphen) do not pad the field _ (underscore) pad with spaces 0 (zero) pad with zeros ^ use upper case if possible # use oppo- site case if possible After any flags comes an optional field width, as a decimal number; then an optional modifier, which is either E to use the locale's alter- nate representations if available, or O to use the locale's alternate numeric symbols if available. ENVIRONMENT TZ Specifies the timezone, unless overridden by command line param- eters. If neither is specified, the setting from /etc/localtime is used. AUTHOR Written by David MacKenzie. REPORTING BUGS Report bugs to <firstname.lastname@example.org>. COPYRIGHT Copyright © 2006 Free Software Foundation, Inc. This is free software. You may redistribute copies of it under the terms of the GNU General Public License <http://www.gnu.org/licenses/gpl.html>. There is NO WARRANTY, to the extent permitted by law. SEE ALSO The full documentation for date is maintained as a Texinfo manual. If the info and date programs are properly installed at your site, the command info date should give you access to the complete manual. date 5.97 May 2006 DATE(1)
Suggestion to Use Dimensional Numbers in Date Representation
The following is a slightly re-formatted version of an e-mail from Neville Holmes suggesting how we might incorporate dimensional numbers into J in order to represent dates. "Dimensional numbers" means numbers with units of measurement embedded in them. For instance, a distance might be in units of meters or light-years.
Date: Sun, 20 Mar 2005 17:46:22 +1100 From: "neville holmes" <holmeswn@YAHOO.COM.AU> Subject: Re: [Jforum] Units calculations in J? To: JFORUM@PEACH.EASE.LSOFT.COM
Preamble Against Building Dimensional Analysis into J
It seems to me that it would be unwise to build dimensional analysis into J. Firstly, it would make the interpreter much more complex, and thus probably slower. Secondly it would make the notation much more complex, which would raise the barrier for casual users and beginners, who are all too often overlooked. Thirdly, there is no single system of units in use, and the ISO system of units is arguably defective anyway. Fourthly, the people who use dimensioned values are primarily engineers and scientists who are probably better suited by being given application packages.
One exception is monetary values, and I have occasionally toyed with the idea that the imaginary part of ordinary numbers could appropriately [be] treated as money to keep it out of the way of real numbers, at least during addition and subtraction.
Exception to this Opposition in Case of Date Values
However, there is one class of very awkward values which I believe J could consistently, conveniently and compatibly handle to the great benefit of casual and inexpert users at least. I refer to time intervals and dates. The following explanation is drawn from my memory of trying to design a decent pocket calculator some years ago, and I hope its fragmentary nature will convey the basic idea satisfactorily.
Examples of time intervals
4w5 four weeks and five days _4w5d6h23m45.23 weeks through to seconds, negative
Examples of dates
1066y4m1 first of April 1066 2005y3m17d12 mid St Patrick's day this year.
In brief, any such value with a month is a date. Maybe a "date" with a 0 year could be this year, and there is a host of other possiblities for special representations.
Arithmetic on dates
Dates could be subtracted to give time intervals. Time intervals could be added to or subtracted from dates. Maybe 1y0&| or something similar could be applied to a date to give the week of the year, and 1m0&| to give the day of the week, and so on. Otherwise, arithmetic on dates would give a domain error.
Arithmetic on time intervals
Ordinary values could generally be applied to time intervals to yield time intervals. Time intervals could be added to, subtracted from, or remaindered into time intervals to yield time intervals, and they could be divided to yield ordinary numbers. (Note that %&1m0 could be used to convert a time interval into an ordinary number giving the value in minutes.) Otherwise, domain errors.
There are a lot of further possibilities which it seems superfluous to do more than name at this stage:
- clock times
- lunar calendar
There are also some matters of details to be considered, such as:
- disambiguating the "m" between month and minute
- handling BC
- mixing other formats
Clearly there's quite a bit of design to be done, but the effect on existing code should be nil, and the complications for the interpreter should be fairly small as what's being done is primarly adding a couple of new types of exact numeric values with very limited domains.
I would suggest that the value of this extension for casual and everyday users would repay the implementation effort, and the capability could attract new users.
Neville Holmes, P.O.Box 404, Mowbray 7248, Tasmania Normal e-mail: email@example.com