Support more Create* methods on OffsetDateTimePattern #267

Closed
GoogleCodeExporter opened this Issue Mar 15, 2015 · 7 comments

Comments

Projects
None yet
2 participants
@GoogleCodeExporter
OffsetDateTimePattern is missing some methods.  It only has one .Create(), 
while other patterns like LocalDateTimePattern have two overloads of .Create(), 
and .CreateWithInvariantCulture() and .CreateWithCurrentCulture().

Original issue reported on code.google.com by mj1856 on 22 Jan 2014 at 10:40

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

It looks like these are inconsistent on the other patterns as well.  There may 
be a few where CurrentCulture doesn't make sense, but we should be as 
consistent as possible across the different pattern types.

Original comment by mj1856 on 22 Jan 2014 at 10:41

It looks like these are inconsistent on the other patterns as well.  There may 
be a few where CurrentCulture doesn't make sense, but we should be as 
consistent as possible across the different pattern types.

Original comment by mj1856 on 22 Jan 2014 at 10:41

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

I tried to do a bit of a tidy-up before 1.2, but OffsetDateTimePattern 
definitely needs improving. (I noticed that myself on a previous SO question.)

There's also inconsistency in terms of the naming of the pre-canned patterns, 
but there are usually good reasons for that (where the alternatives wouldn't 
make much sense). We definitely need to balance consistency and sense, of 
course.

Original comment by jonathan.skeet on 23 Jan 2014 at 6:59

  • Changed title: Support more Create* methods on OffsetDateTimePattern
  • Changed state: Accepted
  • Added labels: Type-Enhancement, Milestone-1.3-consider
I tried to do a bit of a tidy-up before 1.2, but OffsetDateTimePattern 
definitely needs improving. (I noticed that myself on a previous SO question.)

There's also inconsistency in terms of the naming of the pre-canned patterns, 
but there are usually good reasons for that (where the alternatives wouldn't 
make much sense). We definitely need to balance consistency and sense, of 
course.

Original comment by jonathan.skeet on 23 Jan 2014 at 6:59

  • Changed title: Support more Create* methods on OffsetDateTimePattern
  • Changed state: Accepted
  • Added labels: Type-Enhancement, Milestone-1.3-consider
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

This is better as of revision e78207ec87a5. Not sure whether it counts as 
"done" or not, but it may do...

Original comment by jonathan.skeet on 30 Mar 2014 at 3:55

This is better as of revision e78207ec87a5. Not sure whether it counts as 
"done" or not, but it may do...

Original comment by jonathan.skeet on 30 Mar 2014 at 3:55

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

Before calling this done, perhaps we should add culture-aware versions of the 
standard format patterns?

See: http://stackoverflow.com/q/23019131/634824

Also, it seems strange that OffsetDateTimePattern doesn't have culture-aware 
patterns but OffsetPattern does.  One would think that the same patterns that 
work in LocalDateTimePattern would work in OffsetDateTimePattern.  But I can't 
think of any cases where formatting an Offset in any culture would yield a 
different result than in the invariant culture.

Original comment by mj1856 on 11 Apr 2014 at 5:48

Before calling this done, perhaps we should add culture-aware versions of the 
standard format patterns?

See: http://stackoverflow.com/q/23019131/634824

Also, it seems strange that OffsetDateTimePattern doesn't have culture-aware 
patterns but OffsetPattern does.  One would think that the same patterns that 
work in LocalDateTimePattern would work in OffsetDateTimePattern.  But I can't 
think of any cases where formatting an Offset in any culture would yield a 
different result than in the invariant culture.

Original comment by mj1856 on 11 Apr 2014 at 5:48

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

I think that's a different issue, around what patterns are supported by the 
pattern parser rather than what methods are supported by the API - I'll raise 
it separately. (But yes, we need to fix it.)

Original comment by jonathan.skeet on 12 Apr 2014 at 7:39

  • Changed state: Fixed
I think that's a different issue, around what patterns are supported by the 
pattern parser rather than what methods are supported by the API - I'll raise 
it separately. (But yes, we need to fix it.)

Original comment by jonathan.skeet on 12 Apr 2014 at 7:39

  • Changed state: Fixed
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

(Have raised issue 276 for Matt's comment above, btw.)

Original comment by jonathan.skeet on 21 Apr 2014 at 9:59

(Have raised issue 276 for Matt's comment above, btw.)

Original comment by jonathan.skeet on 21 Apr 2014 at 9:59

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

Original comment by malcolm.rowe on 22 Jun 2014 at 12:15

  • Added labels: Milestone-1.3.0
  • Removed labels: Milestone-1.3-consider

Original comment by malcolm.rowe on 22 Jun 2014 at 12:15

  • Added labels: Milestone-1.3.0
  • Removed labels: Milestone-1.3-consider

@malcolmr malcolmr modified the milestone: 1.3.0 Mar 15, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment