Dates in TidBITS

At 16:40 on 13-11-2006, TidBITS Editors wrote:
> All was well and good for a while, but then the forces of logic on
> our staff, as represented by Matt Neuburg, raised the point that if
> the goal was to make it easy for readers to quickly place the
> article at a point in time, wouldn't it make more sense to use a
> different format that leads with the most relevant part of the date
> - the year - and then becomes more specific. In other words, why not
> use this format: (see "Apple Cracks Down on Google AdWords,"
> 2005-10-03). That way, when reading, the first four digits
> immediately tell you if an article is relatively current because it
> was published this year, a bit old because it's from a year or two
> ago, or really old because it's from the 1990s. And if the article
> is current, the month and day then provide the additional
> information necessary to place it more specifically. Swapping the
> month abbreviation for the numeric month also helps in fixing
> chronological locations. You probably don't really care that
> something happened in October of a given year, just that it was
> toward the end of the year, as the numeric month makes clear.

I appreciate the logic behind this decision, but in practice I find
it harder to parse the yyyy-mm-dd format used for article references.
Part of this is because the rest of TidBITS is using dd-mmm-yy and so
my mind is set into that mode of parsing dates (part of this is
because I almost always use dd-mmm-yy myself). So I quickly pick out
the year from the end (if that's what I'm interested in). When I come
across the article reference, I actually have to think about what the
numbers mean. I think that the inconsistency counteracts potential
gains from the logical structuring of the date. I also find having
the month written out more useful -- I associate 'Oct' with autumn
more quickly than associating '10' with a particular time of year.


[Since there's been a grand total of one issue published using these date formats, it's not surprising that YYYY-MM-DD would look odd and seem harder to parse, but I think that will disappear rapidly as you see the more often. Familiarity goes a LONG way toward ameliorating other ills. -Adam]


On a somewhat related point, one thing that I like less about the new
article referencing is that it emphasises the article over the issue.
I still think of TidBITS as a weekly newsletter instead of a large
collection of articles. The new referencing system seems more akin to
a news site that just contains a bunch of articles instead of a
publication where each issue is put together with a specific mix of
articles. I agree that the TidBITS issue number in old article
references was exceedingly difficult for us mere mortals to parse
into an approximate date, but I liked that you were explicitly
referencing an issue of the newsletter.


[Interesting. It's certainly true that we've been issue-centric so far, but that's starting to break down for a lot of reasons. Let's break the discussion of issue-centrism vs. article-centrism out to another thread, since it's related to other things we have planned. -Adam]


Note that I realise that these comments are quite possibly peculiar
to me, so I'm not trying to represent them as some kind of larger
'truth'. I just thought I'd chime in with my thoughts. You didn't
think you could make changes to the minutiae of TidBITS without any
feedback, did you? ;-)


[And Glenn commented in editing that he couldn't imagine people being interested in the date format article. :-) I knew better - this crowd loves nothing more than minutiae! -Adam]

_________________
=> Jolin Warren, Edinburgh, Scotland

At 2006-11-17 06:42 -0800 Victor Guess wrote:

>I have found that using the format: "Meeting Minutes 20061013.txt"
>for files allows them to be sorted much easier in the Finder when you
>are sorting by File Name

Vic - as a supporter of ISO8601, I've been using that idea for a long
time. [Over 40 years ago as a technician learning to wind special
coils, we used (eg) 19650812 as the serial number of the one produced
on that day.] I find it's even better to put the date as the first
item in the filename string. That way all stuff (eg agenda, notes,
formal minutes) associated with a particular meeting stays together.

However, I find it slightly irritating that the "smart" sorting in OS
X puts things out of the order I'd want if I don't always use the
full 8 digits of the date. There are some meetings which happen only
one a month and I tend to use just the year and month to identify
them (eg 200611 rather than 20061111). Folder listings with different
date lengths can become like the following fragment:

200610 agenda.txt
200610 minutes.txt
200611 agenda.txt
200611 minutes.txt
20061005 notes.txt
20061111 notes.txt

Actually, I had to fake that list because TextWrangler's "insert
folder listing" that I used to save some typing reproduces the
filenames in the following (for me, in this scenario) more useful
order:

200610 agenda.txt
200610 minutes.txt
20061005 notes.txt
200611 agenda.txt
200611 minutes.txt
20061111 notes.txt

Of course, the finder doesn't know that those leading numbers are all
dates specified to different precision, it just sees them as 6 or
8-digit numbers, and naturally puts the big ones at the bottom of the
list.

I wonder if there's any option to turn off the FInder's "smart"
sorting - can't remember seeing that anywhere.

regards

Rowland
--
| Wilma & Rowland Carson http://home.clara.net/rowil/
| <rowilclara.net> ... that's Rowland with a 'w' ...

At 2006-11-17 06:42 -0800 Google Kreme wrote:

>I know the YYYY-MM-DD is the ISO standard, but for most uses it seems
>awkward to me as the most important information is last

Google - surely that is a matter of opinion; I'd say that the most
important information to _me_ is _first_ in ISO8601. I'm only
interested in the month and day after I've established whether it's
this year, next year, or 100 years ago.

>I think TidBITS has done a pretty good job over the years with dates

I do agree. It's always been nice to receive a publication from USA
which isn't cramped by the typical parochial outlook.

regards

Rowland
--
| Wilma & Rowland Carson http://home.clara.net/rowil/
| <rowilclara.net> ... that's Rowland with a 'w' ...

At 12:04 on 18-11-2006, Rowland Carson wrote:
> However, I find it slightly irritating that the "smart" sorting in
> OS X puts things out of the order I'd want if I don't always use
> the full 8 digits of the date.

To be fair, the finder is doing the right thing here. I get very
frustrated with systems that don't use 'smart' sorting (with regards
to other files, not the type of use you're talking about). Have you
considered using hyphens to separate the date fields. This makes it
obvious that it's a date, makes it easy to quickly pick out the
month, year, or day, and it will sort properly on any system. This is
what I do for various files where I use the reverse date format at
the beginning of the filename. When I do this with your example, you
get (in the Finder):

  2006-10 agenda
  2006-10 minutes
  2006-10-05 notes
  2006-11 agenda
  2006-11 minutes
  2006-11-11 notes

Hope that's of some help.

_________________
=> Jolin Warren, Edinburgh, Scotland

On 19-Nov-2006, at 21:49, Rowland Carson wrote:
> At 2006-11-17 06:42 -0800 Google Kreme wrote:
>
>> I know the YYYY-MM-DD is the ISO standard, but for most uses it seems
>> awkward to me as the most important information is last
>
> Google - surely that is a matter of opinion; I'd say that the most
> important information to _me_ is _first_ in ISO8601.

In the vast majority of cases when looking at a date the thing I want
to know is the date. Then, the month. Only then, the year. When I
write a check (in theory!), I want to know when I wrote it. Not what
YEAR, as I know that already. If I'm thinking about a check, it was
written in the last 4, maybe 6 weeks. The year is not needed. If I
get a party invitation, I'm assuming it's in the next week or six,
the year is pretty much irrelevant. If I get a letter (hey, some
people still write them) I want to know when it was written, again,
the day is what I'm after.

The only time that yyyy-mm-dd seems to make sense is with machine
sorted files or when dealing with historical data.


[All dates are historical. Eventually. :) -Adam]


So, when dealing with Genealogy records, yyyy-mm-dd is perfectly
reasonable, but for day to day info, the year is largely superfluous.

Smart sorting in Finder goes beyond just dates, it seems to do (what I
consider) the right thing with regular numbers too. For example, I created
some filenames with versioning in the filename:

filename - 9.2.txt
filename - 9.10.txt
filename - 10.1.txt

And it sorted in the same order as the list is shown. I didn't need to pad
the numbers with zero's to make all the numbers the same length.

For the past 20 years I've been using the date system I first saw here in Japan: YYYY.MM.DD (with periods instead of the ISO dashes). My only criterion for choosing it was that since both the US and Europe were "slash systems" that they were confuse-able and therefore inherently compromised, while this "period system" clearly defined itself as being something different and pretty recognizable. Aesthetically I prefer the periods to dashes, but the order works for me.

It's amazing how many alternate systems exist for displaying dates!

The ISO date/time convention shows date and time in the most logical order since it proceeds from the longest time unit to the shortest. One can continue a date-time string by adding hours, minutes and seconds. Perhaps this is more important to science than literature. The problem with existing conventions is the ambiguity if one doesn't know whether the USA or European (and most of the rest of the world!) dating convention is being used in data because both conventions end with the year. This is a particular annoyance in Canada since we tend to use the European convention but have a lot of dealings with the USA. Thus 05.10.2006 (I use dots as delimiters, not a good idea in file names) might be 5 Oct 2006 or May 10, 2006. However 2006.10.05 is clearly ISO and unambiguously 2006 Oct 5. In any convention it's important to use four digits for the year (05.03.02, anyone?). With increasing globalization in communications, avoiding this kind of ambiguity over dates becomes more and more important.

Out with the old and in with the new!

On 23-Nov-06, at 14:21 , Preston Nevins wrote:

> For the past 20 years I've been using the date system I first saw
> here in Japan: YYYY.MM.DD (with periods instead of the ISO dashes).
> My only criterion for choosing it was that since both the US and
> Europe were "slash systems" that they were confuse-able and
> therefore inherently compromised, while this "period system"
> clearly defined itself as being something different and pretty
> recognizable. Aesthetically I prefer the periods to dashes, but the
> order works for me.
>
> It's amazing how many alternate systems exist for displaying dates!

As a genealogist I have run into many situations where I have had to
use a range of dates as I have no idea what was meant.

What date is 01/02/03, assuming that by context it is 2000 and
something?

I use ####/LLL/## as in, 2006/NOV/22 - in the hope that no one will
ever wonder what I meant.

--On 11/26/06 11:18 AM -0800 Mary Arthur wrote:

> I use ####/LLL/## as in, 2006/NOV/22 - in the hope that no one will
> ever wonder what I meant.

As long as they speak English....

Dave

On or about 11/26/06 11:18 AM, thus spake "Mary Arthur"
<maryarthurmac.com>:

> I use ####/LLL/## as in, 2006/NOV/22 - in the hope that no one will
> ever wonder what I meant.

I think that if my name for the eleventh month was "jyu-ichi-gatsu", the
number 11 might be more useful to me. m.

--
matt neuburg, phd = matttidbits.com, http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
AppleScript: the Definitive Guide - Second Edition!
http://www.amazon.com/gp/product/0596102119
Take Control of Word 2004, Tiger, and more -
http://www.takecontrolbooks.com/tiger-customizing.html
Subscribe to TidBITS! It's free and smart. http://www.tidbits.com/

>
>> I use ####/LLL/## as in, 2006/NOV/22 - in the hope that no one will
>> ever wonder what I meant.
>
> I think that if my name for the eleventh month was "jyu-ichi-
> gatsu", the
> number 11 might be more useful to me. m.
>
but don't give in to the temptation!

Many entomologists use Roman numerals for the month, to avoid the
problem of ambiguous date formats on insect labels. For an insect
collected on Nov. 10, for example, the date line on the label would
read 10 - xi - 2006, and everyone familiar with the system knows that
this reads Nov. 10 and not Oct. 11. (Other entomologists would write
out "Nov.") But museum collections are full of specimens with
ambiguous dates, such as "10-11-1995"; if the collector was American,
you assume this was October, unless of course he was living in Europe
at the time...

I use the Swedish date format (year-month-day) for naming files (such
as ongoing correspondence, or a manuscript version), because they
then sort automatically by date when sorted by name. Today's date
would be 061127, and if I was saving today's work on an article I was
writing, the name of the file would begin with "061127_" ....

........................................................................
...............................................
Lawrence Kirkendall +47 55 58 23 42 office
Assoc. Professor, Biology +47 99 60 33 45 cell phone/home
Univ. Bergen, Allegaten 41 +47 55 58 96 81 fax
N-5007, Bergen, Norway

http://www.bio.uib.no/code/staff/forsker.php?pid=1322&lang=N

> >> I use ####/LLL/## as in, 2006/NOV/22 - in the hope that no one will
> >> ever wonder what I meant.
> >
> > I think that if my name for the eleventh month was "jyu-ichi-gatsu",
> > the number 11 might be more useful to me. m.
> >
> but don't give in to the temptation!
>
> Many entomologists use Roman numerals for the month, to avoid the
> problem of ambiguous date formats on insect labels.
>
Why not use (a translation of) the Japanese _long_ date format, that is
"2006<year>11<month>22<day>"
where each of the "<year>", "<month>", "<day>" is a _single_
Japanese character?

Sure, we Japanese say "jyu-ichi-gatsu" to mean "November", but the
"jyu-ichi" is Japanese for "eleven", and the "gatsu" is the "<month>"
character. The "jyu-ichi-gatsu" simply is Japanese for "eleventh-month".

Furthermore, when we write it down, we simply write it "11<month>"
(three characters!) and read it as "jyu-ichi-gatsu".
(No such illogical "****ber" naming of the months!)

So, I would suggest the following format:

2006y11m22d or, maybe 06y11m22d

which is a direct translation of what we use in Japan, every day.
There is no need to use any slashes nor periods, and
"2006y11m22d" consists of the _same_ number of characters as
"2006/NOV/22" (eleven characters).

It is useful, logical, and is without any ambiguity.

Mark Nagata
Translator, TidBITS-Japanese
http://www.tidbits.com/tb-issues/lang/jp/

On Nov 29, 2006, at 3:15 PM, Lawrence Kirkendall wrote:
> I use the Swedish date format (year-month-day) for naming files (such
> as ongoing correspondence, or a manuscript version), because they
> then sort automatically by date when sorted by name. Today's date
> would be 061127, and if I was saving today's work on an article I was
> writing, the name of the file would begin with "061127_" ....

Yes, you can relax and use that format again, now that we're in the
2000s, provided, of course, that you're not dealing with dates from
the 1900s and you're not concerned with anyone who might get confused
by the ambiguity. Some people use that format even crossing the
boundary from the 1900s to the 2000s, and the anomaly in the sorting
is ugly to deal with. When I first encountered that approach to
naming files it was pre-2000, and I found it dismaying for the
ambiguity and the impending missorting, though it was nearly a decade
away. I had previously dealt with a database that stored birth years
as two digits, with a cutoff date at which it would be interpreted as
the previous century (1800s, rather than 1900s), but one year the
earliest and the latest birth years were more than a hundred years
apart, and a thoroughly ugly workaround had to be put in place. That
gave me an enduring distaste for storing years as two digits.

TidBITS is intended for people who understand English, so the
conventions laid out by Adam are reasonable for this context. But
there's also reason behind the ISO standard 8601, because it
establishes a standard which does not depend on language. I'm not
aware of any conventions that would be likely to lead to
misinterpretation of 2006-11-27 as a date. I doubt that even
entomologists would have a problem reading it. And the ISO
representation of a date such as 2006-03-01 solves other problems, as
mentioned earlier in this thread, where as two-digit numbers any one
of the elements could be taken for almost any other.

Back in the days of operating systems that put very low limits on
filename lengths there were compelling reasons for the kind of
collapsing of dates such as you use ("061127_"), but I do my best to
avoid that trap now that I can make the filenames long enough to be
clear, and I stick to the clarity of the ISO standard for dates in
filenames as much as possible (which means whenever the choice is
mine, rather than dictated by a policy I am unable to change).

--
Geoff Odhner

on 11/26/06 2:18 PM, Mary Arthur at maryarthurmac.com wrote:

I use ####/LLL/##  as in, 2006/NOV/22 - in the hope that no one will
ever wonder what I meant.

Don’t you have a problem with the slashes, or is that only in OS10 that they seem to get rejected?

On 1-Dec-2006, at 06:28, J. wrote:
> Don't you have a problem with the slashes, or is that only in OS10
> that they seem to get rejected?

OS X Finder accepts 2006/12/01 without complaint.

It stores the file as "2006:12:01" if you pull out bash and do an ls,
but the Finder shows the slashes.

--
Rent a flat above a shop, cut your hair and get a job, smoke some
fags and play some pool, pretend you never went to school and still
you'll never get it right cuz when you're lay'n in bed at night
watching the roaches climb the wall if you called your dad he could
stop it all.

--On 12/1/2006 5:28 AM -0800 Mark Nagata wrote:

> So, I would suggest the following format:
>
> 2006y11m22d or, maybe 06y11m22d

Which has almost the same problem as 22NOV2006 as far as being
language-specific.

e.g. the French would be 2006a11m22j, the German 2006j11m22t, and so forth.

Dave

On 1-Dec-06, at 06:28 , J. wrote:

> on 11/26/06 2:18 PM, Mary Arthur at maryarthurmac.com wrote:
>
> I use ####/LLL/## as in, 2006/NOV/22 - in the hope that no
> one will
> ever wonder what I meant.
>
> Don't you have a problem with the slashes, or is that only in OS10
> that they seem to get rejected?
>

I haven't had any problems with slashes (10.4.8) - don't remember
that there were with OSX.

On 2006-12-03, at 11:12, Mary Arthur wrote:

> I haven't had any problems with slashes (10.4.8) - don't remember
> that there were with OSX.

Some early version(s) of the OS X Finder, and some other apps, didn't
allow forward slashes in filenames. I don't remember the details,
just getting frustrated as it was unnecessary.


On 2006-12-03, at 11:12, Google Kreme wrote:

> It stores the file as "2006:12:01" if you pull out bash and do an ls,
> but the Finder shows the slashes.

Actually the HFS+ file system stores slashes as slashes--the colon is
still the delimiter. The Unix layer gets colons and slashes
transposed, and they're transposed back to the original for the GUI
layer:

> Another obvious problem is the different path separators between HFS
> + (colon, ':') and UFS (slash, '/'). This also means that HFS+ file
> names may contain the slash character and not colons, while the
> opposite is true for UFS file names. This was easy to address,
> though it involves transforming strings back and forth. The HFS+
> implementation in the kernel's VFS layer converts colon to slash
> and vice versa when reading from and writing to the on-disk format.
> So on disk, the separator is a colon, but at the VFS layer (and
> therefore anything above it and the kernel, such as libc) it's a
> slash. However, the traditional Mac OS toolkits expect colons, so
> above the BSD layer, the core Carbon toolkit does yet another
> translation. The result is that Carbon applications see colons, and
> everyone else sees slashes. This can create a user-visible
> schizophrenia in the rare cases of file names containing colon
> characters, which appear to Carbon applications as slash
> characters, but to BSD programs and Cocoa applications as colons.
<http://www.wsanchez.net/papers/USENIX_2000/>