On 4/23/2013 6:04 AM, Justin Mclean wrote:
It should be able to cope with that. Bit of a moot point as there no Thai
locale for the SDK but I guess you could use copylocale and give it a go.
no, its a different calendar underlying the system. currently its the year
2556BE (buddhist era) which you can obtain by adding 543 to the current CE
year. you can make a gregorian calendar date look like a thai buddhist calendar
date by supplying the thai langauge date parts & adding 543 to the CE year but
it would be wrong.
23/4/56 is a tuesday in the thai buddhist calendar (year 2556BE)
23/4/56 is a friday in a faked thai date using gregorian calendar (year 2556CE).
and in some locales for the buddhist calendar there's a year 0 (want to say in
mayanmar but don't remember exactly).
while there's a lot of correspondence between the buddhist & gregorian calendars
(ie enough that you can fake it w/a wrapper to handle the year part as the
months match up exactly) arabic/persian locales are never going to work that
way. those calendars use completely different calculations.
It probably wouldn't deal with the 6 hour (vs 12 hour) time system but I've
no idea how Thai dates are normally written down do you have some examples?
no need, see above. and in any case, thai time format is 24-hour clock system,
no AM/PM. though informally people use 1-6 plus period of day (late night,
morning, afternoon & evening)--"bye 2" 2nd hour of the afternoon (2:00pm). but
in case you were wondering (full-->short):
13 นาฬิกา 48 นาที 56 วินาที เวลาอินโดจีน
13 นาฬิกา 48 นาที 56 วินาที GMT+7
13:48:56
13:48
where:
นาฬิกา is roughly "o'clock" or time
นาที is minute
วินาที is second
วลาอินโดจีน is timezone name, indochina/ICT
though i think it would be better to supply the CLDR vetted date parts
Would be the ideal solution - no idea how much work that would be.
maybe add another method or change the way the format methods worked. taking
coldfusion as a perfect example ;-) it has lsDateFormat method that has the
following signature
lsDateFormat(date,mask,locale)
where mask can be user supplied but i argue for following the java style of
FULL-->SHORT to avoid crazy/un-parseable date formats.
but to get this to work globally, flex would need more calendars. pretty sure
that would take a lot of work, i wouldn't even no where to begin to swap out the
gregorian calendar for a buddhist one (guessing easiest to port). unless it was
already done & waiting to be donated?
What no Klingon dates? :-)
klingon comes up for inclusion in unicode every so often but the delegates
usually get drunk & start a riot so nothing ever comes of it ;-) but you'd need
a klingon calendar anyway.
