Re: std.dateparse reincarnation
On 10/25/2011 5:23 PM, Walter Bright wrote: Yes, but I've done a fair amount of delegating. Andrei is in charge of Phobos. Is there a list somewhere of who performs what roles, and what people are currently working on (and their queue)? Having something like this would be useful for potential contributors to find their niche.
Re: std.dateparse reincarnation
On Saturday, October 15, 2011 04:21:54 Steve Teale wrote: On Thu, 13 Oct 2011 22:09:39 +0300, Vladimir Panteleev wrote: On Thu, 13 Oct 2011 07:22:06 +0300, Jesse Phillips jessekphillip...@gmail.com wrote: Thought I would let everyone know that while std.dateparse is deprecated and will be removed from Phobos in February, I've updated it to output a std.datetime.SysTime. https://gist.github.com/1283011 I don't have any interest in maintaining it, but since I did use it I updated it for me. Time formatting and parsing seems like a gap of missing functionality in Phobos 2. I've written something to format and parse SysTimes using format strings based on the format PHP uses for its date() function: https://github.com/CyberShadow/ae/blob/master/utils/time.d Feel free to use this file as public domain. Yes, me too. I used to get tremendously frustrated with the old std.date, because all I wanted to do was get the current time and write it into a log file! Do you find that frustrating with std.datetime? Or do you find it to be an improvement? - Jonathan M Davis
Re: std.dateparse reincarnation
On 26/10/2011 02:44, Jonathan M Davis wrote: snip I have not looked over them in detail, but from what I've seen, they're _very_ similar - as in they took the C format specifiers and followed them in almost all (and maybe even all) cases but added a few of their own. But slight differences between them alone don't merit creating a whole new way of formatting dates and times. It isn't a whole new way. A number of date/time format string schemes that make use of repeated letters more or less as mine does have been created over time. I guess because of the combination of natural look and feel, ease of implementation and ease of use. And the LF doesn't seem to me something that people will associate with one such scheme in particular, so there isn't much risk of confusion. Moreover, - If I'm not mistaken, usability is a design tenet of D. It ought to just as well be taken into consideration in designing APIs. - People who want strftime already have access to it. Thinking about it now, I can see parallels with what you've been suggesting: C, C++, Java, etc. - D printf - writef, writefln But given that strftime has evolved haphazardly, how do you plan to make meaningful improvements while keeping most of the specifiers the same? By just picking a random as-yet-unused character whenever you want to add a new format specifier? snip I have yet to look over your API in great detail, Then don't criticise it for not having a certain feature when you haven't read far enough down to discover whether it has that feature. but from what I saw, it looked like _all_ alpha characters were considered flags, whereas strftime uses % to distinguish flags from other characters, just like printf and writeln do. I'll look over your API in more detail, but I would consider that a deal breaker if that's what it does. There may very well be other things that you've done with it which are worth drawing from, but I fully intend to use flags like strftime does. Is Phobos meant to be a community effort or a reflection of the preferences of one individual? Not doing so is unduly restrictive to what you can put in a format specifier. To me it seems no more restrictive than D (even C) string syntax. The need to save for marking the end of the string doesn't place any restriction on what characters may be in the string. And are you using format specifier to mean flag (what I've been using it to mean), format string or the format represented by it? It should be possible to put arbitrary strings in the format specifier just like you would with printf or writeln. Which it is ... unless there's an obscure arbitrary string I've missed. Stewart.
Re: std.dateparse reincarnation
On Friday, October 28, 2011 01:56:40 Stewart Gordon wrote: On 26/10/2011 02:44, Jonathan M Davis wrote: I have yet to look over your API in great detail, Then don't criticise it for not having a certain feature when you haven't read far enough down to discover whether it has that feature. All I was giving was my impression of it given what I had already seen. I was not passing final judgement. but from what I saw, it looked like _all_ alpha characters were considered flags, whereas strftime uses % to distinguish flags from other characters, just like printf and writeln do. I'll look over your API in more detail, but I would consider that a deal breaker if that's what it does. There may very well be other things that you've done with it which are worth drawing from, but I fully intend to use flags like strftime does. Is Phobos meant to be a community effort or a reflection of the preferences of one individual? It is a community effort, but I'm the primary author and maintainer of std.datetime and a member of the core Phobos dev team, so I have a definite say in the matter. And if I think that a particular formatting scheme is inferior for whatever reason, then I'm going to argue against it. And if the core Phobos devs are against something, then it's not likely to get into Phobos. I intend to look over your API in detail this weekend. It may very well be that I'll like it better that strftime, but I'm going to have to look into both in detail and really look at the pros and cons of each based on how std.datetime functions in order to decide what I believe will work best with it - whatever that may be. Already, its design is such that it can't use strftime to do what it does and will have to have its own implementation regardless. I will bring up for discussion whatever I go with in the newsgroup, and it may be that we're going to want to have a formal review for it given the complexities involved, but we'll have to wait and see. I'm not saying that your scheme is necessarily inferior. I was merely stating that from what I could see at a glance, it appeared to be, since based on its initial description, it looks like it can't handle arbitrary strings in a format string, which is a major downgrade from strftime. On top of that, I'm not interested in straying far from strftime without good reason. We'll see what I think of your API once I've examined it in more detail. It may very well be that I'll think that it's far and away superior to strftime and we'll use it whole-hog. I don't know. - Jonathan M Davis
Re: std.dateparse reincarnation
On 13/10/2011 20:09, Vladimir Panteleev wrote: snip I've written something to format and parse SysTimes using format strings based on the format PHP uses for its date() function: https://github.com/CyberShadow/ae/blob/master/utils/time.d Feel free to use this file as public domain. My library includes a date/time formatting facility that's much better than PHP's. http://pr.stewartsplace.org.uk/d/sutil/ Spec of the format string scheme: http://pr.stewartsplace.org.uk/d/sutil/datetime_format.html Walter - when the time comes to implement custom date/time formatting, will you consider using my scheme? Stewart.
Re: std.dateparse reincarnation
On Tuesday, October 25, 2011 20:17:35 Stewart Gordon wrote: On 13/10/2011 20:09, Vladimir Panteleev wrote: snip I've written something to format and parse SysTimes using format strings based on the format PHP uses for its date() function: https://github.com/CyberShadow/ae/blob/master/utils/time.d Feel free to use this file as public domain. My library includes a date/time formatting facility that's much better than PHP's. http://pr.stewartsplace.org.uk/d/sutil/ Spec of the format string scheme: http://pr.stewartsplace.org.uk/d/sutil/datetime_format.html Walter - when the time comes to implement custom date/time formatting, will you consider using my scheme? What does Walter have to do with anything here? He's not implementing any date/time stuff, and he's not all that involved with Phobos development in general. I'm likely the one to be implementing the custom date/time formatting, and the current plan is to do something similar to strftime, since that scheme seems to be fairly standard across several languages. - Jonathan M Davis
Re: std.dateparse reincarnation
On 13/10/2011 05:22, Jesse Phillips wrote:
Thought I would let everyone know that while std.dateparse is deprecated
and will be removed from Phobos in February, I've updated it to output a
std.datetime.SysTime.
https://gist.github.com/1283011
I don't have any interest in maintaining it, but since I did use it I
updated it for me.
The locale detection is broken, as this example shows.
- dateparse_test.d -
import dateparse, std.cstream, std.datetime;
void main() {
string s;
while ((s = din.readLine().idup) != ) {
SysTime t;
dateParse(s, t);
dout.writefln(%s, t);
}
}
- output -
C:\Users\Stewart\Documents\Programming\D\thirdpdateparse_test
12/10/2011
2011-Dec-10 00:00:00
29/10/2011
dateparse.DateParseException@dateparse.d(35): Invalid date string: 29/10/2011
46B4A8
46B31F
402145
402085
403300
40333F
402F3B
49E6F9
49E650
--
Stewart.
Re: std.dateparse reincarnation
On 25/10/2011 20:53, Jonathan M Davis wrote: snip What does Walter have to do with anything here? It was always my understanding that Walter is the man in charge of D development. He's not implementing any date/time stuff, and he's not all that involved with Phobos development in general. I'm likely the one to be implementing the custom date/time formatting, and the current plan is to do something similar to strftime, since that scheme seems to be fairly standard across several languages. What are these several languages? C has it. Thus C++ and D get access to it. PHP has what is just a wrapper around the C library function, which would appear to be there in order to help with porting C code. And what is the aim - to copy some existing scheme, or to have a scheme that is useful, intuitive, extensible, etc.? Stewart.
Re: std.dateparse reincarnation
On 10/25/2011 1:43 PM, Stewart Gordon wrote: On 25/10/2011 20:53, Jonathan M Davis wrote: snip What does Walter have to do with anything here? It was always my understanding that Walter is the man in charge of D development. Yes, but I've done a fair amount of delegating. Andrei is in charge of Phobos. He's much better at library design than I am, though we often talk and argue about how things should be. Jonathan has written much of the date/time code that is currently in Phobos, so he's a natural for integrating in your ideas.
Re: std.dateparse reincarnation
On 25/10/2011 22:22, Jonathan M Davis wrote: snip At minimum, as I understand it, C, Java, python, and Ruby all have similar date/time formatting facilities and use mostly the same flags for date/time formatting. If they're only _similar_, it isn't really a standard. Indeed, it seems to me a potential cause of confusion if these systems, with the same same look and feel and mostly the same format specifiers, have subtle differences. Moreover, how do these APIs deal with an unrecognised format specifier? snip There's a lot to be gained by doing something standard and so any major deviations from strftime need to be solid improvements over strftime for them to be acceptable. My system is both much easier to remember and more extensible than strftime. Does either of these constitute a solid improvement? Moreover, the ease of use makes it a potential candidate for end-user applications, which could pass the user-supplied format string straight to the library to deal with. Just glancing at your scheme, it wouldn't be acceptable IMHO, because it doesn't allow for arbitrary characters in the format specifier (such as putting hours in there as a string). I don't understand. How does what you're talking about differ from literals as given in my spec? It may be easy to use, but on a cursory inspection at least, it doesn't seem to be anywhere near powerful enough. You tell me what features you want adding, and I'll see if I can find a good way to add them. Anyway, I guess I might as well post here the rationale I wrote earlier. -- Many APIs and applications that deal with dates and times include some mechanism for formatting them according to a custom format. Often, this mechanism involves supplying a format string. However, the format of these format strings is normally specific to the application or API. Here are just a few examples: - the to_char function in Oracle and PostgreSQL - the PHP date function - date formatting in Microsoft Excel - the C standard library strftime function - the Acorn Archimedes clock application Many of these systems have their drawbacks, such as complexity, lack of features, or lack of consistency. These can affect both the ease of using the system and the ease of implementing it. PHP's system is simple in comparison, but this simplicity (achieved by making each format specifier a single letter) comes at the expenses of extensibility and memorability. Moreover, intellectual property concerns aside, using a pre-existing format string system would pose the challenge of deciding which one to use. There haven't as far as I know been any attempts to create an open standard for them. Another difficulty with using a pre-existing one is that to add more formatting options I would be creating a fork of the system, and then as my fork and the original diverge there may be format strings with different meanings in the two systems, potentially leading to user confusion. As such, devising a new format string system for my library has turned out to be the way to go. In doing so, I have designed it to avoid the weaknesses I found in the other systems. My system has a number of strengths: - Power - Currently there are 50 format specifiers, compared to PHP's 37. Add to that alignment fields and collapsible portions, which were my own idea. - Logic - The concept of letters distinguishing pieces of information, and lengths and capitalisations distinguishing the ways in which the same piece of information can be formatted, is a nice logical system. - Naturality - This helps to make format strings human-readable. - Extensibility - Plenty of room for more format specifiers to be added in a later version. - Simplicity - The boundaries between format specifiers are straightforwardly defined, making the system easier to understand and implement than (say) the Oracle system. - Memorability - It's far easier to remember a relationship between letters and the data they represent than to memorise all the more diverse Oracle codes or PHP's put-it-where-it-fits single-letter specifiers. - Backward/forward compatibility - Unrecognised format specifiers are illegal - no silently treating them as literals, which may cause the behaviour to change between versions. -- Stewart.
Re: std.dateparse reincarnation
On Wednesday, October 26, 2011 01:54:22 Stewart Gordon wrote: On 25/10/2011 22:22, Jonathan M Davis wrote: snip At minimum, as I understand it, C, Java, python, and Ruby all have similar date/time formatting facilities and use mostly the same flags for date/time formatting. If they're only _similar_, it isn't really a standard. Indeed, it seems to me a potential cause of confusion if these systems, with the same same look and feel and mostly the same format specifiers, have subtle differences. Moreover, how do these APIs deal with an unrecognised format specifier? I have not looked over them in detail, but from what I've seen, they're _very_ similar - as in they took the C format specifiers and followed them in almost all (and maybe even all) cases but added a few of their own. But slight differences between them alone don't merit creating a whole new way of formatting dates and times. There's a lot to be gained by doing something standard and so any major deviations from strftime need to be solid improvements over strftime for them to be acceptable. My system is both much easier to remember and more extensible than strftime. Does either of these constitute a solid improvement? I have yet to look over your API in great detail, but from what I saw, it looked like _all_ alpha characters were considered flags, whereas strftime uses % to distinguish flags from other characters, just like printf and writeln do. I'll look over your API in more detail, but I would consider that a deal breaker if that's what it does. There may very well be other things that you've done with it which are worth drawing from, but I fully intend to use flags like strftime does. Not doing so is unduly restrictive to what you can put in a format specifier. It should be possible to put arbitrary strings in the format specifier just like you would with printf or writeln. - Jonathan M Davis
Re: std.dateparse reincarnation
On 10/14/2011 9:21 PM, Steve Teale wrote: I used to get tremendously frustrated with the old std.date, because all I wanted to do was get the current time and write it into a log file! Are you sure you're worthy? :-)
Re: std.dateparse reincarnation
On Thu, 13 Oct 2011 22:09:39 +0300, Vladimir Panteleev wrote: On Thu, 13 Oct 2011 07:22:06 +0300, Jesse Phillips jessekphillip...@gmail.com wrote: Thought I would let everyone know that while std.dateparse is deprecated and will be removed from Phobos in February, I've updated it to output a std.datetime.SysTime. https://gist.github.com/1283011 I don't have any interest in maintaining it, but since I did use it I updated it for me. Time formatting and parsing seems like a gap of missing functionality in Phobos 2. I've written something to format and parse SysTimes using format strings based on the format PHP uses for its date() function: https://github.com/CyberShadow/ae/blob/master/utils/time.d Feel free to use this file as public domain. Yes, me too. I used to get tremendously frustrated with the old std.date, because all I wanted to do was get the current time and write it into a log file! Steve
Re: std.dateparse reincarnation
On Thu, 13 Oct 2011 07:22:06 +0300, Jesse Phillips jessekphillip...@gmail.com wrote: Thought I would let everyone know that while std.dateparse is deprecated and will be removed from Phobos in February, I've updated it to output a std.datetime.SysTime. https://gist.github.com/1283011 I don't have any interest in maintaining it, but since I did use it I updated it for me. Time formatting and parsing seems like a gap of missing functionality in Phobos 2. I've written something to format and parse SysTimes using format strings based on the format PHP uses for its date() function: https://github.com/CyberShadow/ae/blob/master/utils/time.d Feel free to use this file as public domain. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: std.dateparse reincarnation
On Thursday, October 13, 2011 22:09:39 Vladimir Panteleev wrote: Time formatting and parsing seems like a gap of missing functionality in Phobos 2. It formats and parses specific, official formats just fine, but it doesn't currently support user-defined formats. It's on my TODO list. Eventually, there will be something along the lines of toCustomString and fromCustomString on Date, TimeOfDay, DateTime, and SysTime, where they take a format string defining the custom format. - Jonathan M Davis
Re: std.dateparse reincarnation
On Thu, 13 Oct 2011 12:13:40 -0700, Jonathan M Davis wrote: On Thursday, October 13, 2011 22:09:39 Vladimir Panteleev wrote: Time formatting and parsing seems like a gap of missing functionality in Phobos 2. It formats and parses specific, official formats just fine, but it doesn't currently support user-defined formats. It's on my TODO list. Eventually, there will be something along the lines of toCustomString and fromCustomString on Date, TimeOfDay, DateTime, and SysTime, where they take a format string defining the custom format. - Jonathan M Davis For my use dateparse was actually want I wanted. I was pulling out strings saying, Hey this looks like it might be a date, what do you think? Yeah, cool thank you. I don't wish to try and push it back into Phobos but thought others may well still be interested as I was.
Re: std.dateparse reincarnation
On Friday, October 14, 2011 04:51:58 Jesse Phillips wrote: On Thu, 13 Oct 2011 12:13:40 -0700, Jonathan M Davis wrote: On Thursday, October 13, 2011 22:09:39 Vladimir Panteleev wrote: Time formatting and parsing seems like a gap of missing functionality in Phobos 2. It formats and parses specific, official formats just fine, but it doesn't currently support user-defined formats. It's on my TODO list. Eventually, there will be something along the lines of toCustomString and fromCustomString on Date, TimeOfDay, DateTime, and SysTime, where they take a format string defining the custom format. - Jonathan M Davis For my use dateparse was actually want I wanted. I was pulling out strings saying, Hey this looks like it might be a date, what do you think? Yeah, cool thank you. I don't wish to try and push it back into Phobos but thought others may well still be interested as I was. That's fine. Vladimir was saying that std.datetime's formatting and parsing abilities left something to be desired, so I was pointing out that I do intend to give it the ability to handle custom formats. It's not really my intention at this point that std.datetime gain the ability to take a string representing a date and/or time in an unknown format. There's obviously no problem with you making such code available for those who might want it though. - Jonathan M Davis
