7 ms·
My bank is now y2.1k bug ready: In their CSV export, they changed the date format for the year back to 2 digits. It only takes 23 years to forget history.
by RedNifre 3y ago
My bank is now y2.1k bug ready: In their CSV export, they changed the date format for the year back to 2 digits.
It only takes 23 years to forget history.
- ogogmad 3y agoShould dates be strings?
- paulddraper 3y ago> CSV
- ooterness 3y agoISO8601 / RFC3339 for life.
- deleted 3y ago[deleted]
- somewhereoutth 3y agoYes absolutely. Dates are too complicated, requiring to much context, with too much to go wrong, for any non human readable format. At least with strings other systems have half a chance of parsing them correctly, or at least parsing them in a transparent manner. 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).
- landryraccoon 3y agoIt’s not just a matter of trust. Locale specific datetimes in the future are simply not computable to a point on a number line in the general case. Some locales have date changes that must be determined by the local government every single year. Israel is an example of such a case.
- IggleSniggle 3y agoUnix timestamp (actual reference with easy math) + timezone give you absolute time to work with, such that you can work out the correct presentation for the timezone even if the timezone has undergone multiple revisions in the intervening years. 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.
- landryraccoon 3y agoThe suggested approach simply doesn’t work, because human calendars simply don’t work that way. 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.
- ewi_ 3y agoVery good point, which is a reminder that you have different "types" of dates that you may want to store. 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.
- dragonwriter 3y agoNot really. 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.
- jakobson14 3y agothe question is what format. what you're really doing is storing a slash-separated CSV of integers with only one entry, and storing a set of integers is what many old systems already did. 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.
- mjevans 3y agoDates / timestamps fail to capture an 'event'. At best they are a partial event specification with the assumption that they are converted correctly to an assumed increment along a single time scale. 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/ 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 Note: At the moment Vancouver BC and Seattle WA happen to observe the same time offset but are in different political locales with different DST shift times. I'm not sure if it's still correct to call either timezone PST8PDT... that may imply the USA/CA/Los Angeles. 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.
- doctor_eval 3y agoEveryone - especially those in my own team - told me that dates needed to be human readable strings in my APIs and messages, but I ignored them and used Java time stamps (Unix, but milliseconds) instead. 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.
- ogogmad 3y agoLeap seconds and UTC vs UT1? Even in your use case, this would matter. But yeah, I take your point.
- paulddraper 3y ago> 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. 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 But for every other case, it's much harder to discern the difference. 1695029423495 1695029483502 2023-09-18T09:30:23.495Z 2023-09-18T09:30:25.502Z It's far easier to compare these using the commonly practice of ISO 8601.
- doctor_eval 3y agothat’s the argument I kept hearing, but in practice, it’s trivial. 1695029423495 1695029483502 2023-09-18T09:30:23.495Z 2023-09-18T09:30:25.502Z In fact I can see by just looking at your integer timestamps that it’s about 60,000ms difference, or 60 seconds, so I think your time stamps are wrong. 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.
- q7xvh97o2pDhNrh 3y agoDates should be integer seconds since epoch. Timezones are essentially a UI concept. 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. ;)
- Gabrys1 3y agoNot sure what you mean by passing the timezone as int.
- q7xvh97o2pDhNrh 3y agoEdited a few words and punctuation marks to make my intent clearer; hope that helps. The idea is to deal with the timezone at render-time, not to pass it around.
- ewi_ 3y agoWhen you store the time of a future event (like a reminder for 1 year from now), and integer since epoch does not work. 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.
- mavhc 3y agoDepends what they're for, to say 1000 hours from this point in time, no, to say at 10am in your local time zone in 100 days, yes. If it's in the past, no
- amarshall 3y agoThere have been a few times at work where someone says “people use two digit years, can’t we just store two digit years?” To which I reply: “that’s literally the y2k problem”, usually gets us back to four-digit years.
- bloak 3y agoPersonally I use four-digit years even when I'm writing the date on some food that I'm putting in the fridge -- somethng that needs to be thrown away before the end of the week let alone the end of the century -- but at the same time I'm thinking to myself what a pedant I am.
- vlz 3y agoLet me applaud that! Small redundancies like these in writing lessen ambiguity and cognitive load. Although "2023" is longer than "23" it is more readily apparent as a year when e.g. looking/scanning for dates in the fridge. You might be saving your future brain some precious energy in writing full years instead of shortened ones. (Only half joking, the same could presumably be achieved by a well layed out label with ample white space and good typography.)
- RugnirViking 3y agoWe used to have to write the date at the top of every work page in school and draw a margin strictly with a ruler. At the time naturally I hated the arbritrariness of it but I really appreciate it as an adult. It feels a lot easier to be confident and break away impostor syndrome when you work with little rituals like this. Similar to how I was taught to write with all caps on engineering documents for legibility. It makes very little actual difference, it just feels professional, and I think inspires me to take a little more pride and care in other areas.
- TuringNYC 3y ago>> "It only takes 23 years to forget history." I dont think this means people have forgot history, rather, I think people make tradeoffs. You trade off size/space/ease for long-term disruption. Most developers making these decisions now will be close to a 100yo in 2199. It will not be their problem, or even their childrens' problem. Possibly their grand-children's problem. Alternatively, I could argue that the life of most systems is short enough that 80yrs is too long a horizon to worry about the problem.
- thaumasiotes 3y ago> Most developers making these decisions now will be close to a 100yo in 2199. We're giving people too much responsibility too young.
- NeoTar 3y agoWe’re definitely giving negative seventy year-olds too much responsibility.
- thaumasiotes 3y agoOn the other hand, the ability to communicate with people several decades before they're born should have promising implications for the in-much-higher-demand ability to communicate with people after they've died.
- dralley 3y agoThis is what happens when tech companies start looking down on anyone over the age of 30.