6 ms·

>Having everything work this way makes it so much easier to review code for errors. Had one making me pull my hair put the other day in C#. C# datetimed are me

>Having everything work this way makes it so much easier to review code for errors. Had one making me pull my hair put the other day in C#. C# datetimed are measured in increments of 100 nanoseconds elapsed since January 1st 1 AD or something like that. Was trying to convert Unix time in milliseconds to a C# datetime and didn't realize they were using different units. My fault for not reading the docs but having it in the name would have saved me a lot of trouble.

kqr 5y ago
I'm not sure I agree. When I convert fields to DateTime, I remove the unit suffix from the name. The DateTime is supposed to be an implementation-agnostic point in time. It shouldn't come with any units, and nor should they be exposed by the internal implementation. The factory method used to convert e.g. Unix timestamps to DateTimes, now that should indicate whether we're talking seconds or milliseconds since epoch, for example, and when the epoch really was.
- gregmac 5y ago
  They do: .ToUnixTimeSeconds() .ToUnixTimeMilliseconds() DateTimeOffset.FromUnixTimeSeconds(Int64) DateTimeOffset.FromUnixTimeMilliseconds(Int64) https://docs.microsoft.com/en-us/dotnet/api/system.datetimeoffset.tounixtimeseconds?view=net-6.0 https://docs.microsoft.com/en-us/dotnet/api/system.datetimeo... https://docs.microsoft.com/en-us/dotnet/api/system.datetimeoffset.fromunixtimeseconds?view=net-6.0 https://docs.microsoft.com/en-us/dotnet/api/system.datetimeo...
- stevesimmons 5y ago
  How does the C# DateTime type distinguish between dates and a point in time whose time just happens to be midnight? Much of the C# code I've seen uses names like start_date with no indication of whether it really is a date (with no timezone), a date (in one particular timezone), or a datetime where the time is significant. I'm certainly not a C# developer, though my quick reading of the docs suggests that the DateOnly type was only introduced recently in .NET6.
  - Sharparam 5y ago
    Yeah, before the new DateOnly (and TimeOnly) types, there was no built-in way in C# to specify a plain date. NodaTime[1] (a popular third-party library for datetime operations) did have such types though. [1]: https://nodatime.org/ https://nodatime.org/
eyelidlessness 5y ago
What the heck is with MS and weird datetime precision? I figured out some bug with a third party API was due to SQL Server using 1/300th seconds. Who would even think to check for that if you’re not using their products?
- justsomehnguy 5y ago
  Who would even think to check if the system is counting from 1970/01/01 you’re not using their products?
  - onlyrealcuzzo 5y ago
    This is an established standard. It's really not any stranger than starting dates at 1 CE, or array indexes starting at 0.
    - justsomehnguy 5y ago
      > This is an established standard. Established doesn't mean it is understandable without documentation. Anyone who is not familiar with it doesn't know why it starts in 1970 and counts seconds. You need to actually open the documentation to know about that, and it's name (be it unix time, epoch, epoch time or whatever) doesn't help in understanding what it is and what unit it is using.
      - hannasanarion 5y ago
        The metric system is also not understandable without documentation, byt you don't need to explain it every time because every living person should have gotten that documentation drilled into them at age ten. UNIX time is an easy international standard, everybody with computer experience knows what it is and how to work with it.
        justsomehnguy 5y ago
        > everybody with computer experience knows what it is and how to work with it. Thanks for the laugh. The only ones who needs to know about unixtime is: developers when they do something which takes it/produces it *nix sysadmins Everyone else with "computer experience" could live all their life without the need to know what unixtime is.
pharmakom 5y ago
F# has unit support in the type system :)
- S04dKHzrKT 5y ago
  An example for unfamiliar folks. Many Languages var lengthInFeet = 2; var weightInKg = 2; var sum = lengthInFeet + weightInKg; // Runs without issue but is an error F# [<Measure>] type ft [<Measure>] type kg let lengthInFeet = 2<ft> let weightInKg = 2<kg> let sum = lengthInFeet + weightInKg // Compile time error More info at https://fsharpforfunandprofit.com/posts/units-of-measure/ https://fsharpforfunandprofit.com/posts/units-of-measure/
osigurdson 5y ago
What precisely could have been changed to make you realize that C# DateTime is not the same as Unix time? Perhaps Ticks could be renamed to Ticks100ns but I'm not sure how to encode the epoch date such that it is not necessary to read any documentation. I suppose the class could have been named something like DateTimeStartingAtJan1_0001 but obviously would have been ridiculous. Naming is an optimization problem: minimize identifier length while maximizing comprehension.
- justsomehnguy 5y ago
  > how to encode the epoch date such that it is not necessary to read any documentation And you need to read the docs to know why some systems use 1970 as the reference point. Should we rename it to Unix1970datetimeepoch everywhere?

kqr 5y ago

I'm not sure I agree. When I convert fields to DateTime, I remove the unit suffix from the name. The DateTime is supposed to be an implementation-agnostic point in time. It shouldn't come with any units, and nor should they be exposed by the internal implementation. The factory method used to convert e.g. Unix timestamps to DateTimes, now that should indicate whether we're talking seconds or milliseconds since epoch, for example, and when the epoch really was.

gregmac 5y ago
They do: .ToUnixTimeSeconds() .ToUnixTimeMilliseconds() DateTimeOffset.FromUnixTimeSeconds(Int64) DateTimeOffset.FromUnixTimeMilliseconds(Int64) https://docs.microsoft.com/en-us/dotnet/api/system.datetimeoffset.tounixtimeseconds?view=net-6.0 https://docs.microsoft.com/en-us/dotnet/api/system.datetimeo... https://docs.microsoft.com/en-us/dotnet/api/system.datetimeoffset.fromunixtimeseconds?view=net-6.0 https://docs.microsoft.com/en-us/dotnet/api/system.datetimeo...
stevesimmons 5y ago
How does the C# DateTime type distinguish between dates and a point in time whose time just happens to be midnight? Much of the C# code I've seen uses names like start_date with no indication of whether it really is a date (with no timezone), a date (in one particular timezone), or a datetime where the time is significant. I'm certainly not a C# developer, though my quick reading of the docs suggests that the DateOnly type was only introduced recently in .NET6.
- Sharparam 5y ago
  Yeah, before the new DateOnly (and TimeOnly) types, there was no built-in way in C# to specify a plain date. NodaTime[1] (a popular third-party library for datetime operations) did have such types though. [1]: https://nodatime.org/ https://nodatime.org/

eyelidlessness 5y ago

What the heck is with MS and weird datetime precision? I figured out some bug with a third party API was due to SQL Server using 1/300th seconds. Who would even think to check for that if you’re not using their products?

justsomehnguy 5y ago
Who would even think to check if the system is counting from 1970/01/01 you’re not using their products?
- onlyrealcuzzo 5y ago
  This is an established standard. It's really not any stranger than starting dates at 1 CE, or array indexes starting at 0.
  - justsomehnguy 5y ago
    > This is an established standard. Established doesn't mean it is understandable without documentation. Anyone who is not familiar with it doesn't know why it starts in 1970 and counts seconds. You need to actually open the documentation to know about that, and it's name (be it unix time, epoch, epoch time or whatever) doesn't help in understanding what it is and what unit it is using.
    - hannasanarion 5y ago
      The metric system is also not understandable without documentation, byt you don't need to explain it every time because every living person should have gotten that documentation drilled into them at age ten. UNIX time is an easy international standard, everybody with computer experience knows what it is and how to work with it.
      - justsomehnguy 5y ago
        > everybody with computer experience knows what it is and how to work with it. Thanks for the laugh. The only ones who needs to know about unixtime is: developers when they do something which takes it/produces it *nix sysadmins Everyone else with "computer experience" could live all their life without the need to know what unixtime is.

pharmakom 5y ago

F# has unit support in the type system :)

S04dKHzrKT 5y ago
An example for unfamiliar folks. Many Languages var lengthInFeet = 2; var weightInKg = 2; var sum = lengthInFeet + weightInKg; // Runs without issue but is an error F# [<Measure>] type ft [<Measure>] type kg let lengthInFeet = 2<ft> let weightInKg = 2<kg> let sum = lengthInFeet + weightInKg // Compile time error More info at https://fsharpforfunandprofit.com/posts/units-of-measure/ https://fsharpforfunandprofit.com/posts/units-of-measure/

osigurdson 5y ago

What precisely could have been changed to make you realize that C# DateTime is not the same as Unix time? Perhaps Ticks could be renamed to Ticks100ns but I'm not sure how to encode the epoch date such that it is not necessary to read any documentation. I suppose the class could have been named something like DateTimeStartingAtJan1_0001 but obviously would have been ridiculous. Naming is an optimization problem: minimize identifier length while maximizing comprehension.

justsomehnguy 5y ago
> how to encode the epoch date such that it is not necessary to read any documentation And you need to read the docs to know why some systems use 1970 as the reference point. Should we rename it to Unix1970datetimeepoch everywhere?