DateTime missing function

rgb

Problem

suppose you have a datetime with current date like

Var now As DateTime = DateTime.Now
Print(now.Year) # e.g., 2026

now, want set year to 2000 to year value to your date time

It's hard because you need set complex calculations method AddYear doesn't help 🙂

Proposed Solution

DateTime.SetYear(year As Integer)
DateTime.SetMonth(year As Integer) and for mins, secs......

DateTime.SetValue(year as integer, type as integer) 0 = Year, 1 = Month, 2 = Day......

Example Workflow

Alternatives Considered

Who Would This Help?

bgrommes

I haven't seen this in other environments, and it raises issues with edge cases, e.g., you take leap day and change just the year to a non-leap year.

Why not just create a new date? I'm not offhand finding the docs for the DateTime constructor but in C# it would be along these lines:

newDate = New DateTime(2000,oldDate.Month,oldDate.Day)

Failing that, you could construct a date string and use the parse methods provided.

You would still have to guard against changing Feb 29 to a non-leap year, of course ... either by doing nothing & letting it throw an exception that you handle, or e.g. proceeding to March 1 in a non-leap year. Depends on your intent / needs, so this is something user code should probably deal with anyway.

Garry

Thanks, this makes sense. I agree there is a real gap here, because DateTime currently lets you read components and add/subtract time, but it does not give an easy way to create a new DateTime from specific components.

I am not sure SetYear / SetMonth is the right approach though, because DateTime behaves like a value type. Set... sounds like it mutates the existing value, but the API should probably return a new DateTime.

A possible API would be shared factories:

DateTime.FromComponents(year As Integer, month As Integer, day As Integer) As DateTime
DateTime.FromComponents(year As Integer, month As Integer, day As Integer, hour As Integer, minute As Integer, second As Integer) As DateTime
DateTime.FromComponents(year As Integer, month As Integer, day As Integer, hour As Integer, minute As Integer, second As Integer, millisecond As Integer) As DateTime

And perhaps convenience methods that copy the existing value but replace one part:

d.WithYear(year As Integer) As DateTime
d.WithMonth(month As Integer) As DateTime
d.WithDay(day As Integer) As DateTime
d.WithDate(year As Integer, month As Integer, day As Integer) As DateTime
d.WithTime(hour As Integer, minute As Integer, second As Integer) As DateTime

So your example would become:

Var now As DateTime = DateTime.Now
Var changed As DateTime = now.WithYear(2000)

For invalid dates, I think these should throw an InvalidArgument error rather than silently guessing. For example, changing 2024-02-29 to year 2025 is ambiguous: should that become 2025-02-28, 2025-03-01, or fail? My instinct is that the standard library should fail, and user code can decide how to recover.

What do others think? Is WithYear / WithDate clearer than SetYear, and should invalid dates throw or clamp?

bgrommes

Garry From .NET I'm accustomed to constructors rather than static methods but if you want DateTime to behave like a value type then static methods make more sense. Either (or both!) are fine with me; they all get the job done.

I favor throwing when an invalid value would result -- clients should decide how to handle edge cases as the "right" way to handle it depends on context of the app and its use case. I could even see going to Feb 28 as a possible response in the leap year example.

I like the suite of convenience methods but wonder if some of them being static and some of them "instance" would confuse beginners both in its own right and also by sort of violating the value-like semantics / behavior. Maybe it's best to just have the user specify all the values for the date they want. There's nothing to stop them from doing, e.g., DateTime.FromComponents(2000,someDate.Month,someDate.Day) if they want to crib from an existing variable.

Garry

I've implemented a sweeping reform of DateTime for the next release taking on board this feedback: https://feedback.objo.dev/feature/225