Locale-dependent formatstring for ordering custom dateformat

[zorg]

Hey guys,

I made a few alternate date libraries, that are almost ready for release, but i'm having one last issue with them.

Supporting a function similar in function to os.date, my libs support almost all format specifiers that os.date itself supports.
The exceptions, %c, %x and %X are locale-specific, which means two things; Their ordering of time units can vary, and they may not be the same if they return one as words. (Like, "January" could be returned as "Január" in the hungarian locale)

Since i can get a time structure with the "*t" flag already, my issue is with the first point above; i can get the currently used locale too, but i don't know whether i can get the locale-specific time and date format strings themselves, so that i could replicate those 3 specifiers using my libraries' versions so that their ordering matches the "vanilla" locale-dependent date formats.

In short, does anyone know whether it's possible or not, in some way, to get the time and date format strings that are locale dependent?

[kikito]

I am sorry but I don't understand what you want to do. Can you rephrase what you are trying to accomplish (maybe throwing some code)?

[zorg]

Sure, kikito, and thanks for trying to help, i appreciate it!
So, examples:

Code: Select all

print(os.date("%Y %m %d (%B, %A) : %H %M %S"))
-- This -always- prints in the following format: "2016 01 22 (January, Friday) : 14 15 59", which is near my current time at the moment.
print(ddate("%Y %m %d (%B, %A) : %H %M %S"))
-- This -always- prints in the following format: "3182 1 22 (Chaos, Boomtime) : 14 15 59, which is of course the discordian calendar equivalent of today's date; the hour/month/day part is unchanged here.

Note: online discordian calendar converter

Now, for most %_ format specifiers used, what they return are locale- (and language-) agnostic, that is, those don't modify them in any way.

That i can deal with, and i have.

My issue is that os.date also accepts a few specifiers, like %c, that do depend on the locale, and will give back differently ordered date strings depending on locale:

Code: Select all

local a = require('a') -- nevermind this, just a guard so the forum formats this as lua code
print(os.date("%c")
-- For us/english locale, will print something like "Fri Jan 22 13:23:19 2016", but for a different locale, it might print "2016. Január 22. 13:23:19" instead;
-- the order is not fixed (nor are the same strings guaranteed for day-of-the-week and month-names, but that's a non-issue for me because of the "*t" parameter giving me a table containing all the necessary data about the current month and day of the week.)

Basically, if a user wants to do the following:

Code: Select all

print(ddate("%c"))

without me being able to somehow get the simple time/date format string(s) for the currently used locale, i am not able to programmatically deduce the order of the time units i need to return (nor which ones i even should return)

[kikito]

Does your library do anything other than replicating what os.date already does? Otherwise this might be a bit futile.

Can't you rely on `os.date`? At least for those particular cases? As far as I know, os.date is available in all systems.

[zorg]

Sadly, i can't, since if i only look at what os.date("%c") gives back, let's say, for October 10th, i'll have two separated parts with the number 10 in them.
How could i tell which one is the day and which one is the month?
I even thought of, albeit with discarding plain-lua compatibility, to use luajit's FFI to call some c function to get the needed data, but from what i could find, even c doesn't have any means to return the simple datetime format pattern the current locale uses.

I guess, as a last resort, i could create a function that bruteforces enough variations on the %c specifier to actually be able to reconstruct the currently used format string... except for anything non-numeric;
Reasons being that i'd need to store a bazilion strings for each language's abbreviated and full versions of weekday names and month names.

[s-ol]

I think what kikito really was wondering is why you need to know which part of the string represents which time-unit in the first place and why you don't just do 'return os.time(query)' if there is an unsupported string there.

[ivan]

My issue is that os.date also accepts a few specifiers, like %c, that do depend on the locale, and will give back differently ordered date strings depending on locale:

Code: Select all

local a = require('a') -- nevermind this, just a guard so the forum formats this as lua code
print(os.date("%c")
-- For us/english locale, will print something like "Fri Jan 22 13:23:19 2016", but for a different locale, it might print "2016. Január 22. 13:23:19" instead;
-- the order is not fixed (nor are the same strings guaranteed for day-of-the-week and month-names, but that's a non-issue for me because of the "*t" parameter giving me a table containing all the necessary data about the current month and day of the week.)

Basically, if a user wants to do the following:

Code: Select all

print(ddate("%c"))

without me being able to somehow get the simple time/date format string(s) for the currently used locale, i am not able to programmatically deduce the order of the time units i need to return (nor which ones i even should return)

Unicode has databases for the year/month/date format used for each locale.
I suppose you can deduce that by reverse engineering os.date but that's a bit of a hack.
Remember that old translation project that you helped out with:
https://bitbucket.org/itraykov/cgl/src/ ... ?at=master
https://bitbucket.org/itraykov/cgl/src/ ... ?at=master <-- lua table with all of the formats

One tricky thing is that month names used in this format are not the same as the "standalone" month names.
So "January" as a standalone word could be different than "5 January" in some languages.

[kikito]

I think what kikito really was wondering is why you need to know which part of the string represents which time-unit in the first place and why you don't just do 'return os.time(query)' if there is an unsupported string there.

Yes. Also, unless I'm missing something, you could accomplish everything you want by doing this:

Code: Select all

function ddtate(...)
  return os.date(...)
end

[zorg]

I think what kikito really was wondering is why you need to know which part of the string represents which time-unit in the first place and why you don't just do 'return os.time(query)' if there is an unsupported string there.

Yes. Also, unless I'm missing something, you could accomplish everything you want by doing this:

Because i'd like my own date function to adhere to whatever os.date adheres to when giving a format string, except mine uses a different calendar system, so i need to convert from the standard to mine. What kikito wrote code is most certainly not what i had in mind

The problem comes in when locales cause the specific side effect for os.date (as they cause it for the c equivalents) that there are locale-specific format specifiers that may give back the date string with the units in an order different for each locale. (MM/DD/YY instead of YY/MM/DD and so on)

Since i can't query for these locale specific patterns, i can not replicate this behaviour with my library easily; if i could, i wouldn't have such issues (Except i would, because there's no os.getlocale either, only a setter exists, and how can i be sure whether any environment variable actually contains a locale, or that it's actually what is set for the application to use? (there are programs that can force specific locales on older programs, at least on windows, so getting the global one will be incorrect in that event, but this is another issue that can wait)

As for using os.time, passing my calendar's modified stuff into it so it spits out the correct timestamp is only useful with the bruteforce method, since there's no guarantee how my calendar differs from gregorian (in other words, the date input might error, when it's actually correct); only 5 days per (the equivalent of a week), 5 months / year, the year having a higher unit, like decade or century separated? No notion of a week whatsoever? (If this is what you even meant, that is.)

As for ivan, thank you for reminding me of that great project! If i can somehow access the current locale for datetime stuff, then this issue would indeed be solved with simply having such a list. Well, except when the standard is updated

In any case, and i know i may have should just posted my code from the get-go, i will do so now; i sadly lost the more-complete and clean version in a hdd crash, so i only have one that's a bit more static-y (in that it converts the current datetime into the calendar's representation with one specific formatting.) until i re-write it again.

Though i do wonder, did i really explain this so badly?

[s-ol]

you can use os.setlocale() (without arguments) to get the current locale settings.