Runtime: System.DateTimeOffset Property - StartTimeOfDay

[Connect-a]

I would like to propose a new StartTimeOfDay property that contribute for readability.

e.g.

private static void Main()
{
    var now = DateTimeOffset.Now;
    var midnight = now - now.TimeOfDay;
}

to

private static void Main()
{
    var midnight = DateTimeOffset.Now.StartTimeOfDay;
}

I don't want to make extention methods in 'DateUtil' class.

[nil4]

Did you try DateTimeOffset.Now.Date? That returns 2019-09-27 00:00:00, i.e. midnight at the start-of-today's date.

[Clockwork-Muse]

If you want something that's _actually_ start-of-day, this has to go through a timezone-aware class (and not just something with an offset): DST sometimes starts at 'midnight' local time, meaning you shift 2019-03-27 23:59:59 -> 2019-03-28 01:00:00 (midnight doesn't exist locally).

So which do you want?

I'd have to look at if there's an easy way to get real start-of-day from C# natively. You may have to use NodaTime.

[Connect-a]

@nil4

Did you try DateTimeOffset.Now.Date?

I'm sorry. It seems that my example was not appropriate. What I was wanting is information obtained from an instance of DateTimeOffset. Not just today's date.

Let's suppose I convert and store ISO 8601 data linked from another system, I will be able to write the conversion process more readable and concise.
For example, when I want to calculate a date like "Tomorrow 16:00" from linked data. There is no need to touch the offset when doing this.

[Connect-a]

@Clockwork-Muse
I'm surprised (and terrified) because I didn't know the DST's spec(?). Does it mean that 2019-03-28 00:30:00 does not exist anywhere? It sounds strange.
At least I'm satisfied if I could get the 2019-03-28 00:00:00. But I can't imagine a use case in the DTS area.

[Clockwork-Muse]

@Connect-a
DST varies per each country/region. The EU switches everything at 1AM UTC (so local time of the switch varies). The US switches at 2AM local time (so UTC varies) - in some states/parts of states. Some countries only move 30 minutes. Some countries have 15/45-minute offsets. Some countries switch offsets multiple times a year (or did).

Does it mean that 2019-03-28 00:30:00 does not exist anywhere? It sounds strange.

If I'm reading the time zone map here correctly, that appears to be the case for the Azores. The Azores are in a UTC-1 offset, and are considered part of Portugal (so the EU). Start-of-day would be 2019-03-28 01:00:00.

• There may be other countries that currently switch at midnight local time, and I just don't know about them.
• There may be countries that previously switched at midnight.
• A country might decide to switch a midnight local time at any point in the future.

For example, when I want to calculate a date like "Tomorrow 16:00" from linked data. There is no need to touch the offset when doing this.

If the general case is "I want to calculate Time XX:XX Tomorrow for some time zone", you always need to know the destination _time zone_ (and not the offset), because you have no guarantee some arbitrary local time exists. For that matter, you may not even have any guarantee any arbitrary date exists (Lord Howe Island skipped a day when they switched from a negative to a positive offset, flipping over the International Date Line. Fortunately such cases are rare due to the line being in the middle of the Pacific ocean). In addition, attempting to add even one tick to a date/time value has the potential to require the effective offset be changed, to correctly reflect the official time for a given user/location. Attempting to add things like "1 day" is fraught with danger (attempting to use UTC will give incorrect results).

---

You can attempt to calculate some of this via TimeZoneInfo (although due to compatibility concerns some edge cases may give wrong results). NodaTime can also help a bunch.

What is your actual use case though? What is the problem you're trying to solve? Even something that sounds simple:

Let's suppose I convert and store ISO 8601 data linked from another system, I will be able to write the conversion process more readable and concise.

... is actually troublesome. If these are supposed to be a log of instants of when exactly something occurred, then you could store UTC and be safe. It sounds like you're dealing with future dates, though, at which point you have to do everything in a zone-rules-aware fashion:

• There are three major zone rules databases - are you using the same one?
  
  
  
  • tzdb (aka the Olson database), used by Unix/Linux/most of the internet.
  
  
  • The Windows database (which has different zone ids, and some different rules).
  
  
  • The IATA database (airlines/airports/travel agencies - oh, by the way, UTC for them is Utrecht, Germany)
  
  
• If you're using the same rule database, are you using the same version? These things get updated multiple times a year; some countries have switched DST every year. The current record is 3 days from official notice to the date of the change (Egypt).

That last point is really troublesome, because it means you cannot serialize just UTC - if I schedule a doctor's appointment for 9AM, I want it to _stay_ at 9AM, not mysteriously get moved to 8AM when DST rules change.

... so please, can we get a few more details.

[Joe4evr]

Honestly, you should go use NodaTime for this kind of stuff, because the BCL types will very likely never add support for all the stupid edge cases that humanity has created over all of history.

[Connect-a]

@Clockwork-Muse
I learned a lot of DateTime monster. Thanks so much. I found out that it was unlikely that I could beat it.😇
As you and @Joe4evr said, I understood I should use NodaTime, but It seems that BCL were enough for my work.

If there are no problems, I will close this issue.

[Connect-a]

Sorry for jump to the conclusion.
I feel "time resetting method" is still useful, but I still can't figure out what kind of name is right.

[tarekgh]

I agree adding something like this API can cause confusion. different replies here pointed at that. Start of time of the day (or reset time) can cause more confusing in case of users using some calendars which the day not starting at the midnight. I prefer closing this issue.