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.

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,
Vladimir mailto:vladimir thecybershadow.net

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

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.

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

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

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

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

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.

It was always my understanding that Walter is the man in charge of D
development.

Yes and no. He's the creator of the language and the primary developer on the
compiler (and the only one with commit access I think), but at this point, the
standard library is more of a community effort, and if anyone is in charge of
it, it's Andrei Alexandrescu. Walter does occasionally do work on Phobos, but
he mostly sticks the compiler. There are a core group of developers (of which
I'm a member) who have commit access to Phobos' github repository and are
effectively the gatekeepers for what gets committed to Phobos, but anyone can
submit pull requests.

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"?

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.

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.?

The primary aim is to have one that works well, but we're not going to do
something custom just to do something custom. If there are good reasons to
deviate from what appears to be fairly standard across a variety of languages,
then I'm not necessarily against doing so, but we must have a good reason for
it. 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.
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). It may be easy to use, but on a cursory
inspection at least, it doesn't seem to be anywhere near powerful enough.
- Jonathan M Davis

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.

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

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 L&F 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.

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

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.

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.

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.