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.
It's really not any stranger than starting dates at 1 CE, or array indexes starting at 0.
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.
UNIX time is an easy international standard, 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.
Bullshit.
I never needed to know what unixtime is when I wrote anything with sleep().
All I needed to know is how long in seconds I want the execution to pause for, never ever I needed to manually calculate something from/to unixtime, even when working with datetimes types.
Nobody is saying that the two things need to be connected, the point is that it can be name dropped in a type definition, and you would know what it means.
Windows uses the Gregorian Calendar as its epoch.
It is quite hard actually to disagree with the 100ns tick size that they did use. 1 microsecond may have also been reasonable as it would have provided a larger range but there are not many use cases for microsecond accurate times very far in the past or in the future. Similarly using 1 nanosecond may have increased the applicability to higher precision use cases but would have reduced the range to 100 years. Alternately, they could have used a 128 bit structure providing picosecond precision precision from big bang to solar system flame out with the resultant size/performance implications.
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.
.ToUnixTimeSeconds()
.ToUnixTimeMilliseconds()
DateTimeOffset.FromUnixTimeSeconds(Int64)
DateTimeOffset.FromUnixTimeMilliseconds(Int64)
https://docs.microsoft.com/en-us/dotnet/api/system.datetimeo...
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.
Many Languages
var lengthInFeet = 2;
var weightInKg = 2;
var sum = lengthInFeet + weightInKg; // Runs without issue but is an error
[<Measure>] type ft
[<Measure>] type kg
let lengthInFeet = 2<ft>
let weightInKg = 2<kg>
let sum = lengthInFeet + weightInKg // Compile time error
Naming is an optimization problem: minimize identifier length while maximizing comprehension.
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?