/usr/share/locale & strftime

[alastor933]

A while ago I was made aware of /usr/share/locale by contributions to this thread (thanks, all…).

One interesting tidbit: an LC_time file contains various kinds of day/month names for the locale, but also a few strftime-style format strings. These may be the ones that are used by ‘conversion specifiers’ where the description contains the phrase “.national representation of.”, like %c, %x and %X.
I could use a brute-force method to determine which specifier uses which format string - but why not ask first?
So, does anybody have pertinent knowledge of this?

One LC_TIME string I found puzzling: the last-but-one is “md” in en_US, and “dm” in several European locales.
Not a strftime format string, but what, then?
Could be used to set day-month order generally, which fits with it being ‘md’ in US and ‘dm’ in Europe.

[DJ_Bazzie_Wazzie]

Something like this?

getDate("nl_NL")

on getDate(_locale)
	do shell script "LC_TIME=" & _locale & ".UTF-8 date"
end getDate

[McUsr]

@Alastor933

One LC_TIME string I found puzzling: the last-but-one is “md” in en_US, and “dm” in several European locales.
Not a strftime format string, but what, then?
Could be used to set day-month order generally, which fits with it being ‘md’ in US and ‘dm’ in Europe.

I take a wild guess, and guesses it is timeformatting codes from the cocoa text subsystem.

I don’t think the Cocoa text system covers that!, It may be a part of the strftime specfication then, for short dates or something. I think you are totally right in your assumptions. And I wanted some Emacs key bindings anyway!

(But real men uses Vi, make no mistake of that! It is just that Emacs is built in here, and it is better than nothing, not much but everything helps! )

[alastor933]

@DJ Bazzie Wazzie

getDate("nl_NL")

on getDate(_locale)
	do shell script "LC_TIME=" & _locale & ".UTF-8 date"
end getDate

A-HA! Now this suddenly means something:

ENVIRONMENT
The following environment variables affect the execution of date:

 TZ      The timezone to use when displaying dates.  The normal format is
         a pathname relative to /usr/share/zoneinfo.  For example, the
         command ``TZ=America/Los_Angeles date'' displays the current time
         in California.  See environ(7) for more information.

But there’s more you can pass in, as you showed.
I followed the link to environ(7), and eventually to sh(1), and found the other LC_ variables there - except LC_TIME?
Is it a different beast, or missing?

Something I noted when running your scriptlet: it does not error with a nonexistent locale. It just returns the en_US variant. Expected behaviour?

And you can do this:

getDate("nl_NL")

on getDate(_locale)
	do shell script "LC_TIME=" & _locale & ".UTF-8 date"
	--> "vr 28 sep 2012 19:59:00 CEST"
	do shell script "TZ=America/Los_Angeles LC_TIME=" & _locale & ".UTF-8 date"
	--> "vr 28 sep 2012 10:59:00 PDT"
end getDate

A world clock in 5 lines! What great fun!

[Shane_Stanley]

@McUsr

I take a wild guess, and guesses it is timeformatting codes from the cocoa text subsystem.

I don’t think Cocoa uses the LC_time files.

[McUsr]

Hello Shane, I realized that at least the cocoa text subsystem didn’t use it.

But the cocoa text subsystem has triggers for the buttons on the windows, and can send windows to back!

Interesting to know that Cococa gets its system info from other places. I have read the Systems Overview to lightly!

Btw

I am watching this cool blurred video at google about Hypercard! (lousy quality, 1986). But still very enjoyable Apple Corps of Dallas: Bill Atkinson HyperCard Presentation 12-19-86

[Shane_Stanley]

@McUsr

Interesting to know that Cococa gets its system info from other places. I have read the Systems Overview to lightly!

I don’t know that it’s spelled out anywhere, but I believe they use the UCI libs, which presumably include their own data.

[McUsr]

I see. I have to figure out the subsystems better. And start to use cocoa, which seems like something really enjoyable to program in, brackets or not.

I find the cocoa text system rather impressive!

[DJ_Bazzie_Wazzie]

@McUsr

I take a wild guess, and guesses it is timeformatting codes from the cocoa text subsystem

@McUsr

I see. I have to figure out the subsystems better. And start to use cocoa, which seems like something really enjoyable to program in, brackets or not.

I find the cocoa text system rather impressive!

Just for the record… Cocoa is top level and not subsystem. Date command doesn’t use any cocoa code but as you name it: subsystem. Which is from the kernel perspective just system-level.

[McUsr]

Hello!

Something sometimes get lost in translation. Well, I wrote cocoa text subsystem, which is not the specific way to phrase it. How about the subsystem of cocoa that deals with representation of text? (It is called the cocoa text system several places.) And I have grasped that it isn’t that low level.

I was actually thinking in the orbits, of launchd reading in the values from the lc_locale it needed, and the passing the values of a strftime kind of string over to the cocoa text subsystem, leaving it in charge of the representation of the dates. I have since then realized, that at least what I call the cocoa text system, deals with the editing of text, and tasks around that (cursor and window movement, saving documents and such mainly).

There is really nothing low-lewel about the cocoa text - subsystem either, as it is directly available to the end user.

Yes, I am a fanboy!