|
|
It almost always is ... 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
That message is from 2004! 
Cheers,
विक्रम
"We have already been through this, I am not going to repeat myself." - fat_boy, in a global warming thread 
|
|
|
|
|
Oops. 
|
|
|
|
|
He should keep his day job.
|
|
|
|
|
To be of value it needs to fix an existing problem.
IMO, date conversion is not really a problem.
so, not much value.
put it on github.
I'd rather be phishing!
|
|
|
|
|
samtoad wrote: changing one date format to another form via a function call
What function, DateTime.ToString?
|
|
|
|
|
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.
|
|
|
|
|
PIEBALDconsult:
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.
Thanks....
|
|
|
|
|
Your project? I thought you were talking for a co-worker of yours!
|
|
|
|
|
I'm sure you're proud of it, but don't expect many (particularly on a site of developers) to be likewise impressed.
samtoad wrote: supports 148 different date formats
samtoad wrote: 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.
|
|
|
|
|
Quote: supports 148 different date formats
Oops, I found a 149th: (e.g.) 3rd June 2020.
Oh, and 150th: (e.g. Saturday June 3 2020).
ah, and then there's DD-MMM YYYY, so you need 151.
Sorry, forgot about YYYYMMMMDDDD, I make it 152.
Um, you might be better just using a generic date to string formatter, like pretty much every language (capable of calling a DLL) does already.
And if the list of public holidays serves any purpose, by limiting to the USA you've just eliminated (and alienated) 96% of the world's population from being potential customers
|
|
|
|
|
Besides Excel, SQL Server, BI, Access, and the .NET "Convert" function, one has any number of resources for "importing dates"; which is usually the only time one "converts".
So, the price is what someone wants to pay, where "integrating" said package is probably more trouble than it's worth ... for "a date".
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
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've seen one done by Jon Skeet in C# and Java but he's giving it away
GitHub - jskeet/nodatime: A better date and time API for .NET[^]
To be honest I don't know that it would be sellable as there are free frameworks on time available.
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
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
|
|
|
|
|
Hey fella, I suggest you take a closer look at the https://www.developersdateware.com/supported-date-formats.html page.
Quote: PRODUCT NAME
(SKU #XXXXXX)
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.
Price: $00.00
The lack of a demo & description of the formats is possibly helping put your cash-register into power-saving mode!
|
|
|
|
|
enhzflep wrote: helping put your cash-register into power-saving mode
I'll have to remember that one...
|
|
|
|
|
Quote: changing one date format to another form via a function call.
Jesus wept!
What would anyone use this for? Your library is essentially a 2-line function in standard C (meaning they are available on Windows too) using strftime(3) - Linux manual page[^] and gmtime(3) - Linux man page[^].
How do you expect to charge money for something that the buyer can make themselves with literally 5 minutes worth of work?
Oh, your library also reads time in almost any format? Yeah, not that hard[^].
|
|
|
|
|
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.)
|
|
|
|
|
Quote: 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.
That's a bet I'll be willing to take, because according to his full description (and description in this thread):
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.
|
|
|
|
|
Maybe you are right, with respect to the OP. Nevertheless, I think that you take far too lightly on the issue of date conversions, in a more general sense. No decent solution to date conversions is a five minute job.
I didn't look up his full description, so I took "148 different date formats" as an indicator that he handled a lot of calendars. Now that I see how much glossy finish he has made his marketing of this package, maybe he should rather consider a career in marketing and web design 
|
|
|
|
|
Quote: No decent solution to date conversions is a five minute job.
But he isn't claiming to be able to convert them, he's claiming to read/write different string formats. Writing different date formats is a 5-minute-job.
OTOH, my function (that I linked earlier to decode different input date/time formats) took about 2-hours to write and **still parses almost any input date format** that you'd care to through at it, while ignoring timezones, DST, etc... because those are the difficult parts!
Date/time handling is complicated; this is why I posted the link to the myths developers believe about dates/times. However I don't get the impression that this library (for 175$) does anything other than read/write strings.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
