Hi,

Looks like adding -ve months doesn't rollover the year:

julia> using Datetime

julia> today()
2014-01-08

julia> today()+months(1)
2014-02-08

julia> today()+months(-1)
2014-12-08
*** Should return 2013-12-08 ***

*** The following work alright ***
julia> today()+days(-1)
2014-01-07

julia> dt = date("2014-01-01")
2014-01-01

julia> dt+days(-1)
2013-12-31

julia> today()+years(-1)
2013-01-08

Hope this helps.

Regards,
Ravi

There seems to a problem with the substraction of a Datetime object from an Array{Datetime}:

t1 = datetime(2000, 11, 1)
t_array = [datetime(2001, 11, 1) : month(7) : datetime(2005, 11, 1)]

## --- works as expected
t_array[1] - t1
t1 .- t_array
t1 - t_array

## --- however:
t_array - t1
## ERROR: i not defined
##  in - at C:\Users\scheidan\.julia\Datetime\src\Datetime.jl:358
## WARNING: backtraces on your platform are often misleading or partially incorrect

t_array .- t1
## ERROR: i not defined
##  in .- at operators.jl:83
## WARNING: backtraces on your platform are often misleading or partially incorrect

I'm using Julia 0.2.0-RC4, 64bit on Windows 7.

Hope that helps.

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their tests (if available) on both the stable version of Julia (0.2) and the nightly build of the unstable version (0.3). The results of this script are used to generate a package listing enhanced with testing results.

On Julia 0.3

• On 2014-06-03 the testing status was Tests pass.
• On 2014-06-04 the testing status changed to Tests fail, but package loads.

Tests pass. means that PackageEvaluator found the tests for your package, executed them, and they all passed.

Tests fail, but package loads. means that PackageEvaluator found the tests for your package, executed them, and they didn't pass. However, trying to load your package with using worked.

This issue was filed because your testing status became worse. No additional issues will be filed if your package remains in this state, and no issue will be filed if it improves. If you'd like to opt-out of these status-change messages, reply to this message saying you'd like to and @IainNZ will add an exception. If you'd like to discuss PackageEvaluator.jl please file an issue at the repository. For example, your package may be untestable on the test machine due to a dependency - an exception can be added.

Test log:

INFO: Installing Datetime v0.1.6
INFO: Building Datetime
INFO: Package database updated
ERROR: @test not defined
 in include at boot.jl:244
 in include_from_node1 at loading.jl:128
while loading /home/idunning/pkgtest/.julia/v0.3/Datetime/test/test.jl, in expression starting on line 92
INFO: Package database updated

I'm thinking of porting https://github.com/rmm5t/jquery-timeago/blob/master/jquery.timeago.js to Julia - should it live in Datetime or a separate package?

The following doesn't seem to work:

using Datetime
date(2014,4,1) - months(17)

whereas the following does:

date(2014,4,1) - months(16)

PackageEvaluator.jl is a script that runs nightly.
It attempts to load all Julia packages and run their tests (if available) on both the stable
version of Julia (0.3) and the nightly build of the unstable version (0.4).
The results of this script are used to generate a package listing
enhanced with testing results. This service also benefits package developers by notifying them if
their package breaks for some reason (caused by e.g. changes in Julia, changes in dependencies,
or broken binary dependencies.)

Currently PackageEvaluator attempts to find your test scripts using a heuristic, preferring the
standarized test/runtests.jl whenever present. Using test/runtests.jl allows people to test
your package using simply Pkg.test("Datetime"), with any testing-only dependencies being
installed by looking at test/REQUIRE.

Your package doesn't appear to have a test/runtests.jl file. PackageEvaluator is going to move
away from auto-detecting tests and will instead only test packages with a test/runtests.jl
file. This change will take place in about a month.

You can:

• Add the file and tag a new version. You may in fact have already added this file but not
  tagged a new version. PackageEvaluator only tests your latest tagged verison, so you must tag
  for the file to be detected.
• Chose to do nothing. PackageEvaluator will stop attempting to test your package, and the testing
  status will be reported as "not possible".

If you'd like help or more information, please just reply to this issue.

You say in the documentation that the Datetime has millisecond precision but I do not see how to construct a Datetime with milliseconds, for example:

2009-11-02T09:30:00.001

How can I construct this datetime?

This issue is being filed by a script, but if you reply, I will see it.

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their test (if available) on both the stable version of Julia (0.2) and the nightly build of the unstable version (0.3).

The results of this script are used to generate a package listing enhanced with testing results.

The status of this package, Datetime, on...

• Julia 0.2 is 'Tests pass.'
• Julia 0.3 is 'Tests fail, but package loads.'

'No tests, but package loads.' can be due to their being no tests (you should write some if you can!) but can also be due to PackageEvaluator not being able to find your tests. Consider adding a test/runtests.jl file.

'Package doesn't load.' is the worst-case scenario. Sometimes this arises because your package doesn't have BinDeps support, or needs something that can't be installed with BinDeps. If this is the case for your package, please file an issue and an exception can be made so your package will not be tested.

This automatically filed issue is a one-off message. Starting soon, issues will only be filed when the testing status of your package changes in a negative direction (gets worse). If you'd like to opt-out of these status-change messages, reply to this message.

I think it could be potentially useful to have a 128-bit DateTime type with nanosecond precision. Java's new JSR-310 project which will be integrated into Java 8 talked about having a nanosecond precision type for their default (I couldn't tell if they actually implemented it or not).

Anyway, I'm postponing for now because until JuliaLang/julia#3081 get's resolved, I can hardly work with Int128s on Windows (I guess it could be a UInt128 though....)

Seems like the return value of dayofweek() is inconsistent with the day definition for Sunday. dayofweek() returns 0 for Sunday, while Sunday is defined as 7.

julia> using Datetime

julia> dt=date("2014-01-05")
2014-01-05

julia> dayofweek(dt)
0

julia> Sunday
7

Regards,
Ravi

In commit JuliaLang/julia@bb67ff2 the serialization format was changed, which is to be expected. But this breaks loading Datetime as tzdata and leap seconds are stored in a serialized data file. Perhaps the tzdata should be serialized on the first launch for each user?

It would be a nice enhancement to have a function that returns the number of business days between two dates, discounting Saturdays, Sundays, and holidays. Below is one such implementation that takes two dates and a list of holidays, and returns the number of business days between them:

function bizDays(frmDate, toDate, holidays=[])
  dbw = int(floor(float(toDate-frmDate)/7)*5 + (dayofweek(toDate)>=dayofweek(frmDate) ? (dayofweek(toDate)>5 ? 5 : dayofweek(toDate))-dayofweek(frmDate) : (5-(dayofweek(frmDate)>5 ? 5 : dayofweek(frmDate)))+dayofweek(toDate)))
  dbw -= length(find(h->(frmDate < h <= toDate), holidays))
  return dbw
end

The implementation assumes that the frmDate is always exclusive of the range and the toDate is always inclusive.

Regards,
Ravi

Edit: Corrected typo in variable names

Hey there karbarcca, I wanted a Julian Date conversion, e.g.

# Julian conversion
Base.Test.@test datetime(2452695.625) == datetime(2003, 2, 25, 3)
Base.Test.@test datetime(2456630.375) == datetime(2013, 12, 3, 21)

so I made one; pull request forthcoming. The code is not as golfy as it could be; it was mostly ganked from some javascript...

julia> versioninfo()

Julia Version 0.2.0-rc2
Commit b372a68 2013-10-26 02:06:56 UTC
Platform Info:
  System: Windows (i686-w64-mingw32)
  WORD_SIZE: 32
  BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY)
  LAPACK: libopenblas
  LIBM: libopenlibm

julia> using Datetime

julia> isdefined(:Datetime)
true

julia> date(2103,10,27)
2103-10-27

julia> datetime(2103,10,27,11,10,9)
ERROR: no method datetime(Int64,Int64,Int64,Int64,Int64,Int64,DataType,DataType)

Similar code works well on a 64 bit install

julia> versioninfo()
Julia Version 0.2.0-rc1-prerelease+4163
Commit as/pkgfix/5259264* 2013-10-22 10:33:18 UTC
Platform Info:
  System: Darwin (x86_64-apple-darwin11.4.2)
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
  LAPACK: libopenblas
  LIBM: libopenlibm

julia> datetime(2013,10,27,11,10,9)
2013-10-27T11:10:09 UTC

http://iainnz.github.io/packages.julialang.org/?pkg=Datetime&ver=0.3

Currently, (+,-) are the standard for the Date type, while (<<,>>) work for the DateTime. Using (+,-) with DateTime promotes the DateTime to a Date and performs the operation. The reasoning originally was that users should probably avoid doing DateTime-Period arithmetic operations as it can be potentially confusing/imprecise. Consider the following:

2008-02-29T00:00:00 + year(1)

Should it return 2009-02-28T00:00:00, or 2009-03-01T00:00:00, or 2009-02-27T23::59:59? Basically, should DateTime arithmetic be done with "relative" periods, or "absolute" periods (i.e. 31536000 seconds for a year, no matter leap year, leap seconds etc.). Should we allow both with the use of different operators and avoid any auto-promotion to a Date type?

All things to consider.

The date method takes a string as argument and creates a Date{ISOCalendar} object, but the same doesn't hold true for datetime

julia> string(date(1999,1,1))
"1999-01-01"

julia> date(ans)
1999-01-01

julia> string(datetime(1999,1,1,12,12,12,0,EST))
"1999-01-01T12:12:12 EST"

julia> datetime(ans)
ERROR: no method datetime(ASCIIString)

Is this method being implemented in the base PR?

Hi all,

I am using an older machine with "Ubuntu 14.04 LTS (GNU/Linux 3.13.0-30-generic i686)" installed. And I am using the julia install from the Ubuntu Apt repo. "Version 0.2.1 (2014-02-11 06:30 UTC) | i686-linux-gnu"

When I try to use the now function AND pass a timezone I get the following error in the REPL:

julia> a=now(PDT)
Evaluation succeeded, but an error occurred while showing value of type DateTime{ISOCalendar,Zone109}:
ERROR: type: typeassert: expected (Int32...,), got (Int64,Int32)
in deserialize at serialize.jl:391
in handle_deserialize at serialize.jl:322
in deserialize at serialize.jl:305
in anonymous at no file:107
in open at io.jl:342
in getoffset at /home/mdenson/.julia/v0.2/Datetime/src/Timezone.jl:106
in _days at /home/mdenson/.julia/v0.2/Datetime/src/Datetime.jl:224
in string at /home/mdenson/.julia/v0.2/Datetime/src/Datetime.jl:257
in show at /home/mdenson/.julia/v0.2/Datetime/src/Datetime.jl:263
in anonymous at no file:945
in with_output_limit at show.jl:922
in showlimited at show.jl:944
in writemime at repl.jl:2
in display at multimedia.jl:117
in display at multimedia.jl:119
in display at multimedia.jl:151

A UTC works fine.

Thanks,
Matthew

Joda/JSR-310 has partial types which have potentially useful cases (credit card expirations, birthdays, etc.).

YearMonth would be pretty trivial to implement as we already have addwrap and subwrap for arithmetic. Having those functions for MonthDay shouldn't be too hard.

Hi!

The full code used to test this, and outputs on Windows XP with Julia v0.2.1 and Julia v0.3.0-prerelease+2402 is here:
https://gist.github.com/accerqueira/11403761d7cda61dcfc1

The strangest thing for me, was that

function day_in(day::Date, obj::ObjMember)
  interval = obj.member
  return day_in(day, interval)
end

function day_in(day::Date, interval::DateRange1)
  return day_in(day, [interval])
end

function day_in{C}(day::Date{C}, interval::Array{Date{C}, 1})
  return day in interval
end

worked, but

function day_in(day::Date, obj::ObjMember)
  interval = [obj.member] # cool
  return day in interval # not cool
end

didn't.

Maybe there is something wrong with my installation or my code, although I think Julia is supposed to not let this kind of violations happen... I'm posting here because I couldn't come up with a code that would give this error without Datetime being used...

This is probably the biggest roadblock in my perspective before merging into Base. Up till now, I actually used a pre-generated layout of the tzinfo files, but I'm pretty sure we need something more sustainable and in our control long-term. @aviks, did you say you started some code to translate the olson database? I'm digging through the pytz package for inspiration, but it looks like this is a pain in the butt kind of task.

to fix those ambiguous method warnings

The package name is Datetime, but the module is declared in a file called datetime.jl
Renaming datetime.jl to Datetime.jl solves the problem.

finding indices of intersecting days in two date arrays is not working. for

using Datetime
a = [date(1995, 05, ii) for ii=1:11]
b = [date(1995, 05, ii) for ii=5:31]

we get

julia> findin(a, b)
0-element Array{Int64,1}

although there clearly should be an intersection:

julia> intersect(a, b)
7-element Array{Date{C<:Calendar},1}:
 1995-05-05
 1995-05-06
 1995-05-07
 1995-05-08
 1995-05-09
 1995-05-10
 1995-05-11

Another example would be

a = [date(1995, 05, ii) for ii=2:31]
b = [date(1995, 05, ii) for ii=5:21]

with

julia> findin(a, b)
6-element Array{Int64,1}:
 15
 16
 17
 18
 19
 20

and

julia> intersect(a, b)
17-element Array{Date{C<:Calendar},1}:
 1995-05-05
 1995-05-06
 1995-05-07
 1995-05-08
 1995-05-09
 1995-05-10
 1995-05-11
 1995-05-12
 1995-05-13
 1995-05-14
 1995-05-15
 1995-05-16
 1995-05-17
 1995-05-18
 1995-05-19
 1995-05-20
 1995-05-21

Do you have a method to create a datetime from a unix timestamp ?

Date and time functionality is so basic that I'm starting to feel like having it in Julia Base would be best. The main problem is that timezone data and leap second data need to be updated more often than one may want to update Julia itself. Maybe those can be included in point releases while ensuring that point releases are non-disruptive enough that people are willing to make those updates even for production systems.

Similar to DateRange1, which takes an anonymous boolean function as its step, need to figure out a similar setup for DateTimes.

The problem is you probably don't want to return individual second of a day for inclusion (or maybe you do in some cases?) In any case, it would probably be helpful to be able to still specify a step for DateTimeRange1 that would indicate how the iteration happened when applying the inclusion function.

I'm not sure why the parsing is failing for these particular cases:

julia> Datetime.dt2string(Datetime.DateTimeFormat("mm/dd/yyyy"),"18/05/2009")
2009-01-05T00:18:00 UTC

julia> Datetime.dt2string(Datetime.DateTimeFormat("mm/dd/yyyy hh"),"18/05/2009 16")
2009-01-05T00:18:00 UTC

julia> Datetime.dt2string(Datetime.DateTimeFormat("mm/dd/yyyy hh:mm"),"18/05/2009 16:12")
ERROR: invalid base 10 digit '/' in "18/05/2009 16:12"
 in error at error.jl:21
 in int at string.jl:1519
 in dt2string at /Users/jiahao/.julia/Datetime/src/Datetime.jl:193

julia> Datetime.dt2string(Datetime.DateTimeFormat("mm:dd:yyyy"),"18:05:2009")
2009-01-05T00:18:00 UTC

julia> Datetime.dt2string(Datetime.DateTimeFormat("mm:dd:yyyy hh:mm"),"18:05:2009 16:12")
ERROR: invalid base 10 digit ':' in "18:05:2009 16:12"
 in error at error.jl:21
 in int at string.jl:1519
 in dt2string at /Users/jiahao/.julia/Datetime/src/Datetime.jl:193

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their tests (if available) on both the stable version of Julia (0.3) and the nightly build of the unstable version (0.4). The results of this script are used to generate a package listing enhanced with testing results.

On Julia 0.4

• On 2014-08-30 the testing status was Tests pass.
• On 2014-09-01 the testing status changed to Tests fail, but package loads.

Tests pass. means that PackageEvaluator found the tests for your package, executed them, and they all passed.

Tests fail, but package loads. means that PackageEvaluator found the tests for your package, executed them, and they didn't pass. However, trying to load your package with using worked.

This issue was filed because your testing status became worse. No additional issues will be filed if your package remains in this state, and no issue will be filed if it improves. If you'd like to opt-out of these status-change messages, reply to this message saying you'd like to and @IainNZ will add an exception. If you'd like to discuss PackageEvaluator.jl please file an issue at the repository. For example, your package may be untestable on the test machine due to a dependency - an exception can be added.

Test log:

>>> 'Pkg.add("Datetime")' log
INFO: Installing Datetime v0.1.6
INFO: Building Datetime
INFO: Package database updated

>>> 'using Datetime' log
Warning: imported binding for Date overwritten in module Datetime
Warning: imported binding for DateTime overwritten in module Datetime
Warning: Method definition now in module Dates at dates/conversions.jl:21 overwritten in module Datetime at /home/idunning/pkgtest/.julia/v0.4/Datetime/src/Datetime.jl:294.
()Julia Version 0.4.0-dev+450
Commit 90bf63c (2014-08-30 12:41 UTC)
Platform Info:
  System: Linux (x86_64-unknown-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

>>> test log
Warning: imported binding for Date overwritten in module Datetime
Warning: imported binding for DateTime overwritten in module Datetime
Warning: Method definition now in module Dates at dates/conversions.jl:21 overwritten in module Datetime at /home/idunning/pkgtest/.julia/v0.4/Datetime/src/Datetime.jl:294.

()ERROR: test error in expression: t .+ year(2) == [year(3),year(3),year(3),year(3),year(3)]
`.+` has no method matching .+(::Array{Year{ISOCalendar},1}, ::Year{ISOCalendar})
 in anonymous at test.jl:81
 in do_test at test.jl:47
 in include at ./boot.jl:246
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:285
 in _start at ./client.jl:354
 in _start_3B_3602 at /home/idunning/julia04/usr/bin/../lib/julia/sys.so
while loading /home/idunning/pkgtest/.julia/v0.4/Datetime/test/test.jl, in expression starting on line 63

>>> end of log

This is a fun behavior:

#Correct
julia> datetime(2013,7,1,12,0,0,0,offset(hours(-6)))
2013-07-01T12:00:00 -06:00

#Gigantic hours number
julia> datetime(2013,7,1,1259,0,0,0,offset(hours(-6)))
2013-08-22T11:00:00 -06:00

Feels like we might want to attach an error to hours > 23 like there is on the month:

#No 13th month
julia> datetime(2013,13,1,12,0,0,0,offset(hours(-6)))


BoundsError()
while loading In[28], in expression starting on line 1
 in totaldays at /home/rzwitch/.julia/v0.3/Datetime/src/Datetime.jl:101
 in datetime at /home/rzwitch/.julia/v0.3/Datetime/src/Datetime.jl:153 (repeats 2 times)

julia> Datetime.datetime("yyyy-MM-dd HH:mm:ss", "2011-04-01 00:00:00")
2011-04-01T00:00:00 UTC

Looks like the plans are coming right along.

Would it be possible to have a function that return the name of the month of a given date as a string? Example:

monthname(date(1985,6,21)) ==> "June"

A possible addition would be to be able to tell the function to return a three letter truncated version of the name.

Since the differing-only-by-capitalization thing is a bit awkward. Just a thought.

I don't think the current date algorithms handle negative years very well (BCE dates).

Here's a weird idea: Datetime types have something -- maybe everything -- in common with Real numbers.

I was thinking about generic programming and how things that are like real numbers could inherit a lot of functionality. Specifically I was thinking about a histogram of a collection of Date{ISOCalendar} but it probably applies to lots of types, Datetime and otherwise.

If I change a line at the top of Datetime.jl to:

abstract AbstractTime <: Real

and provide a more generic histrange{T <: Real} (the implementation in statisitcs.jl is specialized for <: Integer and <: FloatingPoint but it can be dealt with) and I ignore 100 warnings when using Datetime then I can do this:

using Datetime
d=today()
ds=[d,d,d+day(2),d+day(1),d+day(10)]
drange = histrange2(ds,5)
for hd in histrange2(ds,5)
    @show hd
end
@show drange

and get something semi-intelligible:

hd => 2013-12-25
hd => 2013-12-27
hd => 2013-12-29
hd => 2013-12-31
hd => 2014-01-02
hd => 2014-01-04
hd => 2014-01-06
drange => 2013-12-25:0001-01-02:2014-01-06

It makes me wonder about the possibilities.

Right now the default timezone is always UTC, which is good for performance reasons, but it could be expected that the default timezone be whatever the user's system is set to. I'm pretty sure there are C routines to check this somehow that we could tap into if we wanted.

julia> Datetime.dayofweek(Datetime.date("2014-02-02"))
0

julia> Datetime.Sunday
7

Looks like the problem is here:

dayofweek(dt::DateTimeDate) = (_days(dt) % 7)
...
const Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday = 1,2,3,4,5,6,7

Either Datetime.dayofweek should return 7 rather than 0 for Sunday or Datetime.Sunday should be set to 0.

Hi, I'm using julia to read data files with hourly observations. These also include data at midnight, recorded as 24:00 rather than 00:00. This gives an error upon reading, for example:

DateTime("2018-01-01 24:00","yyyy-mm-dd HH:MM")
ERROR: ArgumentError: Hour: 24 out of range (0:23)

It might be good to make an exception for 24:00, changing to 00:00 the next day, but I'm not sure how/where to change this. (I have little experience with julia so far). Thanks for advice!

https://www.youtube.com/watch?v=-5wpm-gesOY&feature=youtube_gdata_player

See JuliaLang/julia#7319

Hi,

the format of you datetime is that way "2013-01-01T00:00:00 UTC" and the standard iso8601 is a bit different : 2014-03-18T21:29:15Z or 2014-03-18T21:29:15+00:00, is there a way to modify the toString function ?

Not sure if you knew about this test failure

INFO: Installing Datetime v0.1.6
INFO: Building Datetime
INFO: Package database updated
ERROR: test error during t .+ year(2) == [year(3),year(3),year(3),year(3),year(3)]
`.+` has no method matching .+(::Array{Year{ISOCalendar},1}, ::Year{ISOCalendar})
 in anonymous at test.jl:62
 in do_test at test.jl:37
 in include at ./boot.jl:245
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:285
 in _start at ./client.jl:354
while loading /home/idunning/pkgtest/.julia/v0.3/Datetime/test/test.jl, in expression starting on line 63
INFO: Package database updated

Datetime.jl line 370 has a typo where "for" is "fyor"...hence it fails.

Here is a Chinese date in the common Western calendar:

julia> date("2009年12月01日")
ERROR: Can't parse Date, please use date(format,datestring)
 in date at /Users/jiahao/.julia/Datetime/src/Datetime.jl:155

julia> methods(date)
#10 methods for generic function "date":
date(x::DateTime{C<:Calendar,T<:Offsets}) at /Users/jiahao/.julia/Datetime/src/Datetime.jl:61
date(y::Int64) at /Users/jiahao/.julia/Datetime/src/Datetime.jl:138
date(y::Int64,m::Int64) at /Users/jiahao/.julia/Datetime/src/Datetime.jl:138
date(y::Int64,m::Int64,d::Int64) at /Users/jiahao/.julia/Datetime/src/Datetime.jl:138
date{C<:Calendar}(y::Int64,m::Int64,d::Int64,cal::Type{C<:Calendar}) at /Users/jiahao/.julia/Datetime/src/Datetime.jl:138
date(y::Union(Period,Real)) at /Users/jiahao/.julia/Datetime/src/Datetime.jl:139
date(y::Union(Period,Real),m::Union(Period,Real)) at /Users/jiahao/.julia/Datetime/src/Datetime.jl:139
date(y::Union(Period,Real),m::Union(Period,Real),d::Union(Period,Real)) at /Users/jiahao/.julia/Datetime/src/Datetime.jl:139
date{C<:Calendar}(y::Union(Period,Real),m::Union(Period,Real),d::Union(Period,Real),cal::Type{C<:Calendar}) at /Users/jiahao/.julia/Datetime/src/Datetime.jl:139
date(s::String) at /Users/jiahao/.julia/Datetime/src/Datetime.jl:146

Currently, it seems that the only way you can parse this correctly is with

 Datetime.dt2string(Datetime.DateTimeFormat("yyyy年mm月dd日"), "2009年12月01日")

A series of dates in MM/dd/yyyy format is inconsistently parsed without throwing errors

julia> date("18/05/2009")
2009-05-18

julia> date("08/05/2009")
2009-08-05

The date constructor apparently looks for dd/MM/yyyy, which silently falls back to MM/dd/yyyy. This is quite a gotcha when parsing an array of dates in a consistent string format and this behavior of date's default string parsing could at the very least be documented better.

[jiahao: changed mm to MM for months instead of minutes]