The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Just to add a comment on your approach: when you say "I have a coworker/friend who has produced a ..." and "he does not know what to sell these key routines for" that doesn't inspire any confidence in his abilities: if he can't work out how to find a site, sign up, and post a message then in all probability his computer knowledge and skills are extremely poor.
That's not saying your skills are poor, or your friends skills are poor - but that's the impression that divorcing yourself from the request gives.
Generally speaking, you need to come over as professional and knowledgeable to sell software: if you want to sell to professionals at least. If you want to sell to student then forget it: they will pirate it or copy'n'paste from SO anyway ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
Maybe if it's for some language/framework which doesn't have anything like that built-in.
Certainly not for .net, which has good date/time parsing and formatting support already.
Or are you talking about converting between different calendars? Which is of very little use in the modern business world.
The main shortcoming with such a plan is that while you can sell applications, you really can't sell utility/library functions which form the foundations of applications.
Those sorts of things are given away freely so others can build applications.
Furthermore, consider I bought a library of functions from you for $10. Then I reverse-engineer them, using your library to help validate the correctness of mine (or finding bugs in yours). Maybe I could even do bench-mark testing to show that mine is faster. Then I offer copies of my version for $5 each, on the same platform you use, maybe even with source code. I'd need to sell only two copies to get my money back and the rest is gravy.
I think the more profitable model continues to be the "if you like it, please consider donating a few bucks to a poor starving developer in his mother's basement" model.
Thanks for the kind feedback!. This is the first time I have done this.
Just for thought, my project is a Date Conversion Software Package that supports 148 different date formats. It supports six date delimiters. The actual DLL software library written in "C". There is a DLL function call that can perform date conversion from one to another date format.
I'm sure you're proud of it, but don't expect many (particularly on a site of developers) to be likewise impressed.
supports 148 different date formats
can perform date conversion from one to another date format
These statements are already red flags for me. They imply that you have grabbed the wrong end of the stick.
One big issue with "conversion from one to another date format" is that having dates and times as strings within an application is generally going to lead to trouble. It is far better to parse into a structure, use it, then format it if necessary.
The main thing to consider is how we might convert a date/time "from one to another date format" with .net (if we ever actually wanted to do that at all).
.net provides System.DateTime and System.DateTimeOffset structures, each with a few methods for parsing strings, and each with a ToString Method.
Those methods take parameters for specifying the format.
See also Custom date and time format strings | Microsoft Docs[^]
This is a very flexible way of doing this and much better than hard-coding "148 different date formats".
The application developer is able to specify those few formats the application may require.
The application can parse an incoming value, use it as needed, then only format it into a string when it comes time to output it.
Plus the fact that it's written in C and is expected to be distributed by DLL means that it isn't multi-platform.
Will you compile and provide versions for other Operating Systems?
Many of us on CodeProject use .net and that means that we'd have to use P/Invoke to call your routines -- but, of course, we'd use the built-in routines instead.
Dates and times are not strings, you need to stop thinking of them as strings.
I certainly can agree with a lot of those who have commented: Making a solution to a solved problem is not a big profit opportunity.
Yet... In a Western framework, we have very limited understanding of calendar issues in a global framework. Date.ToString() may be far from sufficient. I was working with some Koreans: If you asked them about their age, they first had to convert their lunar calendar to a sun calendar, and then correct for their convention of giving your age as the year of your living: At birth, you are starting your first year, not your zeroth.
Another case: When I was working with web archiving, there were native Americans who wanted access control to their archived web pages to be restricted by their concepts of season: Some documents should be accessible during the seeding season only, others only during the harvesting season. (They also wanted some documents to be available to males only, others to females only - but that is not calendar related.)
Some Asian cultures restart their year count from some astronomical or social event, indicating the base as part of their year indication - similar to our BC/AC, but on a lot more dynamic scale.
And so on. Date.ToString() does not cut it. MS has done a lot to support various calendars, but you can't take for granted that it is supported in all applications. (In those I devlop, there is certainly not support for all sorts of Asian calendars!)
So there may be a market for the library that the TS (or some "coworker/friend" of his) has created - but mostly in Asian markets. Western software developers generally ignore such issues, taking for granted that the only calendar adaptations required is adapting to the time zone and 24/12 hour clocks.
Lots of Western software have no chance of succeeding in Asia, because the developers have no understanding of Asian culture and the requiremnts that the software should satisfy.
This is an interesting discussion. I've been writing software in umpteen environments (for use only in the UK though) for over 40 years. If there is one thing that STILL causes trouble, regardless of language, libraries, OS etc - it's dates: conversion and date arithmetic. This is despite all the manifest libraries and OS supported date formats etc.
I've written, or extended, date manipulation libraries etc over the years because none of them do eveything I need. (Borland C++'s Date Class was particularly lacking I seem to remember!) I was doing some elapsed time processing in Excel only the other day and realised that the calculation was occasionally a day out because of the fractional time element that was being stored internally after extracting times and dates from an external database, so had to find a way to 'round' the dates.
Having not used all possible libraries or environments, maybe there is one out there that can handle (correctly) all the possible permutaions of date representations in all languages and for all time-zones and counting systems, but I'd be very surprised. Certainly I am still regularly having to account for the unexpected behaviour of Microsoft's Date objects in various edge cases after using them since the dawn of Windows 3!
Dates are difficult, especially if you mix in people's interpretations of them: If I was to say that something was going to happen "overnight Tuesday at 2 am" would that be early morning on Tuesday or Wednesday, for example. 8)
There's no way to make money from selling code for converting dates, even if that code converts between dates in different calendar systems. To be used one has to supply either the source code or a DLL (or similar), and as soon as it's been released it's likely to be widely available on the net (for use at no charge). The only way such code can repay the time and effort spent in development is by being incorporated in a date conversion application -- see examples here -- but I suppose there's very little demand for such software.
I bet your friend/coworker is a junior dev like you.
Why would anyone in their right mind pay for something that's widely available for free, and even already available in most modern frameworks (for the last 20 years)?
I think y'all would do society a bigger service if you went back to sweeping standing water off sidewalks.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
DESCRIBE THE PRODUCT HERE. FOR EXAMPLE: You can enjoy THIS BENEFIT using THIS FEATURE OR using THIS FEATURE you can DO WHAT YOU WANT TO DO. YOU CAN MAKE THIS DESCRIPTION AS LONG AS NECESSARY.
The lack of a demo & description of the formats is possibly helping put your cash-register into power-saving mode!
I suspect that what the OP is talking about is something else. You are talking about formatting a "Western style" date into a text string, while (I suspect) that the real problem is converting between calendar systems. Like those based on the moon, rather than on the sun. Year being reset when a new emperor comes to power. History is essential, so you have to relate to the Western calender having a discontinuity at year -1 to 1 (year 0 doesn't exist). Maybe you have to relate to the old bug in Lotus 1-2-3 considering 1900 as a leap year (which it isn't)! Maybe you have to relate to both Julian and Gregorian Western calendars (and remember that different countries switched from Julian to Gregorian at different times, so to translate a date from Western to another calendar, you may have to know the geographical origin of the date, to determine whether it is Julian or Gregorian).
The more you study calendars and dates on an international scale, the more messy it becomes. It is certainly not a five-minute job to handle all alternatives. There are libraries, and Windows provides support for quite a few variations; I am not sure that Linux developers have cared enough about any culture that is outside their programming lab to implement a full complement of non-Western calendars. Or spanning the transition period from Julian to Gregrian. Or handling the missing year zero.
I doubt very much that the library of the OP handles absolutely everything, but I am sure it handles a lot more than your five-minute-job. Then, I question how large is the market for such a "complete" library - I would guess very close to zero in the Western world. In Asia, the need is probably a lot higher. But marketing in Asia is so different from marketing in the West that I don't think very many of us Westeners can provide much valuable and helpful advice on the matter. (But of course there may be Asian people in this forum with a good understanding of how to successfully market a product in Asian countries.)
It only mentions recognition of the US, no international and/or global claims are made.
It produces a date in a string form, and that is all it is claimed to do (no conversion).
If the description could mention special support for leap years, but not say anything about non-western support, about timezone handling, about locale awareness, about different calendar support and also doesn't do anything with dates than reformat them, then it probably doesn't do all the things you imagine it to do.
So yes, my 5 minute job handles everything in the description as it stands. Time/date handling is insanely complicated to those of us (like me) who've had to implement it, hence if the ad for a time/date API specifically leaves out the hard bits and only promises to do the easy bit, then it's a sure bet that that is all it can do.
I've run into 50% of the problems in this list, hence I know what to look for in a time/date API. The poster doesn't address a single thing there.
Last Visit: 31-Dec-99 19:00 Last Update: 7-Mar-21 11:55