jackstouffer / date-parser Goto Github PK

the old version of emsi_containers in the latest tagged release of dateparser (2.1.1) doesn't compile with recent dmd, so a release of date-parser with the updated dub.json would be useful.

Sep 2003 sounds more like (1 september -> 30 september 2003) rather than 1 september 2003.

Maybe everything should be parsed as interval 2003/09/01 ==> ( 2003/09/01 00:00:00.0000 2003/09/01 23:59:59.9999) . Maybe a [) interval works better.

Then from code you can ignore interval and take only interval begin if it's ok for you.

Instead of an interval a couple date, duration can be used too.

#!/usr/bin/env dub
/+ dub.sdl:
dependency "dateparser" version="~>3.0.2"
+/

import std.stdio;
import std.datetime;
import dateparser;

shared static this() {
}

void main() {
  writeln(parse("2260-12-25"));
}

in main it's ok:

$ dub ab.d 
2260-Dec-25 00:00:00

But, if in static this:

shared static this() {
  writeln(parse("2260-12-25"));
}

void main() {
}

$ dub ab.d 
Program exited with code -11

I'd like to ignore timezone with this code

assert(parse("Sat, 12 Mar 2016 01:30:59 -0900", null, /* ignoreTimezone */ true) == SysTime(DateTime(2016, 3, 12, 01, 30, 59)));

but I got the output

core.exception.RangeError@../../.dub/packages/dateparser-master/src/dateparser.d(1142): Range violation

Having the source files in the global scope makes no sense. Restructure everything to under dateparser, e.g. dateparser.parse.

This is a breaking change.

You can't view any function/class docs from the link in the readme. E.g. try https://jackstouffer.github.io/date-parser/dateparser/parse.html

This is the default string format javascript applications output which some servers actually use for serving to their frontend...

Would be great to have this supported. Examples:

Thu Nov 07 2019 17:00:00 GMT+0000 (UTC)
Mon Dec 09 2019 16:26:16 GMT+0100 (Central European Standard Time)

Removing the extra comment (UTC) or (Central European Standard Time) at the end seems to be enough to fix this but this might actually be useful if this was already done from inside the library.

For now I'm using a custom parse function which pre-processes the string:

auto parseDate(const(char)[] s)
{
	import dateparser : parseDateRaw = parse;

	if (s.endsWith(")"))
    {
    	auto end = s.lastIndexOf('(');
		if (end != -1)
        	s = s[0 .. end].strip;
        return parseDateRaw(s);
	}
    else
    	return parseDateRaw(s);
}

This fails

import std.range;
import std.utf;
import std.datetime;
import dateparser;
import std.experimental.allocator.gc_allocator;

class RusParserInfo : ParserInfo
{
    this()
    {
        super(false, false);
        monthsAA = ParserInfo.convert([
            ["янв", "Январь"],
            ["фев", "Февраль"],
            ["мар", "Март"],
            ["апр", "Апрель"],
            ["май", "Май"],
            ["июн", "Июнь"],
            ["июл", "Июль"],
            ["авг", "Август"],
            ["сен", "Сентябрь"],
            ["окт", "Октябрь"],
            ["ноя", "Ноябрь"],
            ["дек", "Декабрь"]
        ]);
    }
}

void main()
{
    auto rusParser = new Parser!GCAllocator(new RusParserInfo());
    immutable parsedTime = rusParser.parse("10 Сентябрь 2015 10:20".byChar);
    assert(parsedTime == SysTime(DateTime(2015, 9, 10, 10, 20)));
}

Removing the byChar makes it work due to auto decoding, but this is indicative of a larger problem.

the current version of emsi_containers is 0.9.0, can we relax the dependency specification to be more general (to even higher version of emsi_containers in future update)?

Many uses of dateutil's parser include parsing times of the day in relation to the current date. This is not currently possible, so there should be an API for adding a default date to apply the given information on top of.

This would be a breaking change

The indirection from CAllocatorImpl is too costly. The functions should call the allocator directly instead.

This would be a breaking change.

Currently, only strings with char encoding can be parsed; this must be fixed. The main blocker to this is ParserInfo, which uses string for it's AA keys. ParserInfos are initialized separate from the parser function, so it has no knowledge of the encoding type of the string being parsed.

Ranges of graphemes should be supported as well.

Hello, can you privide some method to parse intervals like

5 sec, 20 min, 20min 30sec,1 month 5hour, etc