Should dates be strings?
Lo, nobody complained about the readability because most time problems are relative to other events, rather than to a specific clock time. It’s so much easier to work out that two events occurred a few milliseconds apart when you don’t need to take segmentation (ie: ymdhms.s) into account. And using an integer obviates time zone and daylight savings corner cases. You can simply subtract two numbers and get useful information. And it’s much easier to do the math in your head and in scripts.
For those relatively rare times that you do need to know the clock time, there are CLI tools (ie, date -s) and websites galore.
Of course my use case was not everyone’s use case. But I ignored the blanket recommendation to use human readable time, and despite the naysayers, life became much easier for me and my team. I doubt that I would go back to string timestamps for any purpose.
Honestly, human time is for humans, it’s a presentation problem. Computer time is for computing.
But yeah, I take your point.
IF you know they occurred a few milliseconds apart, integers are marginally easier.
1695029423495
1695029423502
2023-09-18T09:30:23.495Z
2023-09-18T09:30:24.502Z
1695029423495
1695029483502
2023-09-18T09:30:23.495Z
2023-09-18T09:30:25.502Z
1695029423495
1695029483502
2023-09-18T09:30:23.495Z
2023-09-18T09:30:25.502Z
I personally find that it's much more difficult to compute the number of seconds between two different ISO timestamps without help, and that’s my point.
Or to put it another way, they cannot be trusted to engineers to get it right every time. Let's face it, even something as simple as floating point numbers have serious issues when implemented in computer systems (so another candidate for strings quite frankly - notable that JSON is strings all the way through).
There's still a bunch of problems (timezone of event origin? Event reporting origin? Server? Client? Client + presentational overlay?) and confusing things to work through (including relativistic problems) but the consistency of the reference point is valuable. Nobody is going to confuse what timezone you are using as your point of reference when you use Unix epoch. Just use a 64-bit number to hold it.
If the state of Indiana decides this year to change when they set their clocks forward and back, and you stored your appointment datetime as a timestamp, when do you show up for an appointment? At the new 930 AM after statutory date adjustment, or the now incorrect time stamp in your database? Will the DMV respect your claim that you had an appointment at epoch timestamp 1726651800, or will they say sorry buddy the clock on the wall says 9:30 AM, you missed your window? Are your taxes next year due at 1713173400, or are they due at midnight April 15th?
This is NOT a UI issue. This is an issue where the timestamp you calculated in the past literally does not mean the same calendar date in the future as it does now.
And if your answer is to recalculate the timestamp based on locale changes, what was the point of storing the timestamp? (I hope you stored an audit trail of the locale as well as the timestamp, otherwise you can't even recompute the timestamp). The timestamp is never the ground truth, the human readable string is the ground truth.
The timestamp for a particular human date time is not generally a computable function, because human governments change how dates are reckoned frequently, and the human government, not your database are the ground truth.
Went storing the time at which an event happened (e.g. for a system log) then a UTC or UNIX time works, and it will be transformed at display time depending on the user's timezone.
When storing a future time at which to do something, it should be stored with its target timezone so you can always make sure it happens at the right moment. For this iso datetime representation makes a lot of sense.
On the other hand, the state of Indiana could just as easily solve most of our time issues by passing a law declaring a day to be exactly 24 hours ;)
The date value should always be stored and passed around as an int — and then only transformed into a user-readable string on the client-side at render-time, only when it's necessary for a human to read it. It's the job of frontend code to take in the date as input (still as an int), detect the reader's timezone, and render accordingly.
For some systems, you may want more precision, in which case millis (or nanos) are reasonable, as long as you choose a big enough int type to hold them.
Once humanity goes from 1 planets to N planets, the whole thing will become a mess again thanks to relativity, and software engineers of the future will have to deal with figuring out how to convert an Earth timestamp to a Martian timestamp — and what it even means for two timestamps to be "equal" then.
But that's next century's problem. ;)
Your event is initially in the user's timezone (e.g. 10am 20th of June 2024 in France), if you store it as a number then you are fixing the exact second at which it will happen. However, if the timezone in question has some changes you didn't anticipate (new law voted, no more summer time), then you will either be triggering your event 1h before (e.g. 9am instead of 10am) which is probably not what your user wanted, or you'll have to recompute all your timestamps to take that change into account.
Instead, you could store rhe event with the target timezone, and let your datetime library that is up to date figure out next year.
This is a really interesting scenario that I hadn't considered at all. You're totally right; this approach breaks down there.
Off the top of my head, it looks like this scenario would require manual action either way, though. Either it's an update of the packaged datetime library to incorporate this new regulation, or it's a database migration to update the timestamps for affected users.
Sometimes they are, sometimes they are not.
For example...date+time of birth. The legal date (timezone) is a significant part of this event's time.
> passed around as an int
We're talking about a CSV. CSV don't have ints.
You can use base-10 encoding of the Unix timestamp, or the ISO 8601.
I would add that a UI might prompt for a date as well, which of course would be entered using a local time input element based on the the users time zone. But that local time would immediately be converted to an int and passed to an API.
I mean, sure, serialize them as ISO8601 strings, but, no, dates are fundamentally not strings, and that shouldn't be their basic internal representation in most sane systems.
In CSV, though, everything is strings. But the question there is what string format.
the real solution is to store 64-bit seconds (or perhaps 96-bit microseconds, if you need precision) since some epoch, like jan 1st 1970. it's a simple integer that monotonically increases with a defined starting point. you can't get any more simple or reliable than that.
the unix time stamp was a wonderful solution, they just chose to use too few bits for how long their system would end up living. 64-bit integer seconds will last something like 42x the age of the universe, so that ought to cover things.
Event specification is a very complex and politically entwined idea. This involves not just a frame of reference for the time, but also a location within which that time should make sense. Otherwise it is impossible to derive the correct rule-set for evaluating the human interpreted value of that moment.
An alternative which might make sense is to force people to specify which ruleset they desire with the offset value within said ruleset.
Sadly, my preferred representation of time isn't expressed in either of the popular standards (RFC 3339 or ISO-8601). https://ijmacd.github.io/rfc3339-iso8601/
RFC 3339 gets closet to my preference with: 2023-09-17 23:51:41Z
However these are examples of what I'd prefer to see:
* 2023-09-17 23:51:41 Z UTC
* 2023-09-17 16:51:41 PST8PDT USA/WA/Seattle
* 2023-09-17 16:51:41 PST8PDT Canada/British Columbia/Vancouver
Time would be expressed numerically 'large endian first' format, with zero or one punctuation element between units, preferably expressed with individual units matching the most correct (easiest for a human to read what they expect) value at a glance. This means - (or no separation) for dates, and : (or no separation) for HMS. (Space) or _ (Underscore) are preferable for between units. The timezone 'name' follows the smallest unit of time, which is itself followed by the reference city. Implicitly events in the past were accurate at the time they were encoded, while events in the future might need re-validation and conversion if the rules have changed. Though it would be even smarter for the human important metadata (a string, probably) of recognizing the future event(s) be stored rather than a precise moment which may be incorrect.
However not all times are generated within such references. Most frequently (when sampling human facing outputs) times are printed within some other reference frame. As I tried to elaborate that usually relates to political realms, and there even cities may not be a sufficiently precise specification. (Offhand E.G. would timestamps from east and west Berlin while it was divided differ? I've not memorized that trivia, but it is one example of a politically divided city.)
Further, not so many decades ago timezones along the western Americas coast happened to match, but have since diverged at times during the year due to political changes in timezone observations. It is not inconceivable that actions at a state, county, city, or other zoning level (E.G. Provences for Canada) might further change the meaning of a human friendly representation of an event (time in a place).
Would rather convert to unix at the time the event is recorded since we will be able to convert to the unix standard from whatever locale. If we store timestamps with a locale then we have to worry about the exact type of locale changes that you mentioned, and there is no guarantee that we will even know how to translate the locale that was stored at the time the TS was created. Sure, unix could change too (e.g. leap seconds), but I would be much more confident that time libraries will handle such changes
Otherwise this isn't going to be a meaningful discussion.
at any rate, if you even want to have a hope of keeping track of any of that stuff, you're going to need a rigorous and atomically-precise physical standard to actually map it all to. look at the tz database. it's a set of mappings that ultimately rely on such a standard of atomic-backed time.
It isn't. See leap seconds.
Using a string would allow you to distinguish UTC from UT1. Only UT1 is monotonic.
https://en.wikipedia.org/wiki/Unix_time
"Unix time is a date and time representation widely used in computing. It measures time by the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, the Unix epoch, without adjustments made due to leap seconds."
Unix time does not include leap seconds or other adjustments.
[Edit] From Wiki, your code is subtly mistaken:
> When dealing with periods that do not encompass a UTC leap second, the difference between two Unix time numbers is equal to the duration in seconds of the period between the corresponding points in time. This is a common computational technique. However, where leap seconds occur, such calculations give the wrong answer. In applications where this level of accuracy is required, it is necessary to consult a table of leap seconds when dealing with Unix times, and it is often preferable to use a different time encoding that does not suffer from this problem.
Would you prefer if I used the article's term of "precise time"?
At any rate, it's a lot better to use precise time timestamps, as a single integer of seconds/miliseconds/vibrations of a caesium atom>, than a dumb "01/01/99" string of integers that rolls over and breaks at Y2K. (with associated fun parsing bugs)
No, it is not always better. If you want to store when a contract is going to end you don't want care how many milliseconds are between now and then. You care that it happens exactly at midnight of the last day of the year. Not an hour earlier or later. Even when politicians intervene between now and then.
If you can't establish accurate precise time, you have no ability to handle all that political crap layered on top. You're trying to solve a top-of-stack problem in the bottom-most layer.
Look at the tz database, the way in which the problem you think needs to be solved is actually handled. It implements all your mushy ever-changing political end-of-day end-of-week crap as a table of conversions to precise-time seconds.
If it's in the past, no