![Click to see original Image in a new window](javascript:CaricaFoto("http://cdn.slidesharecdn.com/ss_thumbnails/oopadventureswithxoops-121001010800-phpapp01-thumbnail-2.jpg");)
I read your post almost 3 times but i still fear i could not understand it totally.
Quote:
Storing dates and times in the standard database format allows you to perform queries based on those "standardized" dates.
Quote:
Internally the date/time is normally stored as so many seconds since a certain time/date but is seldom accessed directly in that manner.
do you mean there is just one unique standard database format as i mentioned before as "int"?
so i can show you my prev example in more detailed manner:
In local persian:
Database int("2012-07-11")----formatTimestamp---> jdate local---> "1391-04-21" --> userside
In general (english):
Database int("2012-07-11")---formatTimestamp---> userside
Quote:
Sounds like to "globalize" we just need a way to convert back and forth between different calendar types.
please as i stated in the first post do not conflict between "localization/internationalization" and "globalization". They are not in contrary with each other nor have any relations. they are completely different concepts. you can localize without globalize or globalize without localize or you can do both or none of them.
[off topic]
globalization examples in xoops: using google recaptcha, sfs, xortify cloud, relations with social networks like twitter, facebook and ...
[/off topic]
Quote:
do it in a manner that we can use generic statements to store or retrieve the data that would translate for the different calendars.
I already show you how we can retrieve using current xoops local function "formatTimestamp". Also I can show you the local way of storing (the backward way)
eg using the current core functions (userTimeToServerTime, strtotime):
In local persian:
Database int( "2012-07-11")<-- userTimeToServerTime <--- strtotime---- "2012-07-11"<--- inputTimeToGregorian local <--- "1391-04-21" <--- userside
In general (english):
Database int("2012-07-11")<-- userTimeToServerTime <--- strtotime---- "2012-07-11" <--- userside
Quote:
By this I mean you could set your site to use a calendar and all the display and entry of the site would use the preferred calendar but it would still store them in the database in the format the database desires
excellent, the best explanation of date/time localization.
Quote:
but by using these core routines that take care of the conversion for you they do the "dirty" work
No. not at all. the above using formatTimestamp function to localize output date/time is the cleanest way i can imagine.
no core file is hacked. the function is just located in language/persian/locale.php
same we can do for input date/time.
currently strtotime is not localized. you can find some examples in the core files like this one in modules/system/admin/mailusers/main.php
$time = strtotime(trim($_POST['mail_lastlog_max']));
if ( $time > 0 ) {
$criteria[] = "last_login < $time";
core developers should localize "strtotime" or define a new xoops function for input date/time from scratch.
see this feature request:
http://sourceforge.net/tracker/?func= ... roup_id=41586&atid=430843
Quote:
Then promote the use of these core routines to module developers.
rather than that IMO we should force them. eg: now if they dont use "formatTimestamp" it will considered as a bug.
Mamba wrote in another topic:
Quote:
In the near future, we'll need to convert News from fpdf to tcpdf, so all modules are consistently using tcpdf, and we can provide tcpdf as part of XOOPS library.
excellent approach. but tcpdf is above 10MB.
