I think you have totally missed the intention of my posts. I never asked you to prove anything or doubted your skills, I asked to see how you would tackle the challenge. I was interested in how you would go about it.

All you had to say was you don't have time or don't want to. Why you have to make a big drama out of everything I don't know.

If you would, then you would satisfy the 2 algorythms, I gave you.

I think this was provocative, and based on my English knowledge, I feel, it questioned my abilities, and was ironical, I felt..

If you did not wrote with that intention, then my apologies, but I doubt, that was intended to be a straight message... IMHO.

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

du calme...

Webmaster33 can I have your script? Is it free?
This would be very useful... If I had that script before...
Thanks
Max
The one with Mac OS X Server 10.4 :)

Lets not drag this on further than necessary :)

I explained my intentions, if you are accusing me of lying then that's your perogative.

Edit: Oh well perogative must be spelt wrong as I can't find it in the dictionary

prerogative

---

Fractured Atlas :: Liberate the Artist
Services: Healthcare, Fiscal Sponsorship, Marketing, Education, The Emerging Artists Fund

Right you are!

I would have never guessed at that r being there

Now, now, let's calm down.

The second solution above certainly seems the most logical, but in fact it is not the most logical in terms of how most people think. Both solutions, in fact, as well as the date_add and date_sub functions in GT::Date, have what seems to be quite a significant flaw - basically, they oversimplify what a "day", "month", or "year" means.

For example, 3 hours before 03:30 is usually 00:30, but could be either 23:30 or 01:30. The second way does a better job due to the fact that unix times are time-zone and daylight-savings independant.

Consider the following two times:

1004233600
1004320000

They are 86400 seconds apart - 24 hours, in other words. This would be acceptable for an add/subtract_hours function called with 24 hours, but would not be acceptable for a add/subtract_days function called with 1 day. The reason can be shown here:


From a non-pragmatic (i.e. users') point of view, that seems wrong. Consider a calendar application - it can reasonably be argued and expected that setting a reminder for "1 day from now" should happen at the same time tomorrow. Obviously, as a programmer, I can appreciate that this doesn't "make sense" pragmatically, but as a user of an application, that is the behaviour I would expect. Likewise, adding any other unit larger than hours needs to also take into account that it map overlap these boundary - and possibly even multiple times.

The situation becomes even more vague and imprecise when you get up to to adding months - what should happen if I try to add 1 month from January 29th, 30th, or 31st? I would expect the last day of February - which could be anywhere from 28 days to 31 days. Then leap days come into effect, and must be considered as well (1 month from Feb. 15 should be Mar. 15, regardless of whether or not there is a 29th of February).

However, there is still another problem that needs to be considered where the server is in a time zone where daylight savings has taken effect, while a user may be in a time zone where the daylight savings time either does not happen, or starts at a different time (for example, there is a difference, if I remember correctly, of about 2 weeks between the commencement of daylight savings time in Europe and North America. Using a blanket "time_offset" variable (or two of them that work together, as is done in Gossamer Forum) is more of an easy hack than a real solution. I'd love to be able to add a "select your timezone" feature to Gossamer Forum, rather than making users enter an offset from the server time.

So in short, yes, we do need a date (not unix time) manipulation library. We have discussed this internally and we agree on this fact. So it will be done - the only question is when. Right now, however, our focus is on stabilizing and enhancing our existing products - such as the recent beta releases of Community and the Links SQL shopping cart plugin). So, basically, we agree with you, but at the moment we have more pressing development that we feel deserves a higher priority.

---

Jason Rhinelander
Gossamer Threads
jason@gossamer-threads.com

Date modules are so complicated - rather you than me :(

Jason,
I'm grateful for your detailed answer! I really enjoyed it!

Yes, my suggested solution was for clean dates, not for timezoned dates. It is another thing to have functions which can also treat time zones correctly. It's the same thing as you have date_get and date_get_gm functions.

Also you showed me some good examples for those cases, e.g. when doing operations with months. Yes, I aggree. These are exceptions, should be handled in the function. Of course these functions will be more complex than the one I described.

That's good enough for me. I did not expect suggestions as quick change, just suggested that would be fine to have them.
Thank you very much!
Of course developments with higher priority, should be the first!

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Maxpico,
Thanks for your interest!

Let me tell some words about the date convert script developments... I decided developing the convert date script because I did need it for Links 2.0. You can find my posts in that subject if you search for them in Links 2.0 forums. When I finished the v1.0 version, it was the first perl script ever I done. The 1.0 version did work fine. It was 3 years ago. Since I basically created for myself, I didn't plan to release it. However I saw the public demand for such script, so I decided to improve it, and planned to sell it for developers for reasonable price. At that time there was such date module which would satisfy my needs, and probably other's too. Therefore I developed the 2.0 version. But before I would ever release it I would need to create a module from it. At that time I did not have that knowledge, additionally in the meantime appeared a module which does the same, what my script does.
So I will never finish development of convert date script, because there are already module solutions, which knows much more than my script.
One was Class::Date (can find on CPAN or the dev site here: http://hacks.dlux.hu/Class-Date/). Yeah, he is also Hungarian who did such nice module.
The other was GT::Date, what I currently use. IMO, if GT::Date would not exist, I would use Class::Date for sure.

Now back to my script:
# Description: Converts any date into any other date format (doesn't compute or validate dates, just changing their format)
# Usage: &convert_date ($date, $input_format, $output_format, $language);
# Example: &convert_date ('09-11-1998', 'dd-mm-yyyy', 'yyyy.mmm.dd.', 'English');
# Format strings: yyyy, mmmm, mmm, mm, dddd, ddd, dd, HH, MM, SS
# Notes:
# - input format MUST match the input date format
# - ddd and dddd will be always based (computed) on the given input date
#Changes in v2.0beta3:
# - some small bug changes
#Changes in v2.0beta2:
# - strict usage - hopefully now is mod_perl compatible
# - multi level debug added
# - exception added to convert special partial formats
#Changes in v2.0beta1:
# - completely reworked algorithm for format converting
# - error messages added, error checking works fine as I know
# - now validates dates, prints error message if a date element is not valid
# - added support for yy format. e.g. dd/mm/yy
# Known problems:
# - no support for GMT & UTC time zones (yet)
# - no support for 12-24 hour format converting (yet)
# - no support for language to language converting
And as I mentioned earlier, can convert dates correctly from any format to any format, to unix time and from unix time back to chosen format, also can display date languages in many language, including Hungarian, German, English, French, Russian, Spanish, and probably more automatically, just by setting the correct locale.

As for the used tag format, as Paul suggested a few years ago, probably I would change the formatting to use ``%tag%'' style instead of just using ``tag'' (if I would finish the script).

I will likely never release the script for the public. There are better date converting modules, I mentioned.
Also I would not want, that Paul and maybe other skilled programmers would munching on my 2 year ago used programming solutions... Using my current knowledge I would do it module based, likely better structured, and faster.

Finally I attached the test results file of my script (test_result.txt). See the results yourself.

If you checked the test results and still find the script useful, we can discuss about my date converting script privately.

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...