Comment on CFCs

• SpaceCowboy@lemmy.ca ⁨9⁩ ⁨months⁩ ago

  You also don’t store dates in a string that you’ll have to parse later. I’ve had to deal with MM-DD-YYYY vs. DD-MM-YYYY problems more times than I can count.

  And you understand that you could have a date in unix time and leave the time to be midnight, right? You’d end up with an integer that you could sort without having to parse every goddamn string first.

  And for God’s sake if you insist on using strings for dates at the very least go with something like YYYY-MM-DD. Someone else may someday have to deal with your shit code, at the very least make the strings sortable FFS.

  source

  • cqthca@reddthat.com ⁨9⁩ ⁨months⁩ ago

    You don’t have a line that checks the format and auto converts to your favorite?

    source
  • BorgDrone@lemmy.one ⁨9⁩ ⁨months⁩ ago

    You also don’t store dates in a string that you’ll have to parse later

    Depends. If the format is clearly defined, then there’s no problem. Or could use a binary format. The point is that you store day/month/year separately, instead of a Unix timestamp.

    And you understand that you could have a date in unix time and leave the time to be midnight, right?

    source

    • SpaceCowboy@lemmy.ca ⁨9⁩ ⁨months⁩ ago

      First of all, midnight in what timezone? A timestamp is a specific instant in time, but dates are not, the specific moment that marks the beginning of a date depends on the timezone.

      What are you talking about? The same problems apply no matter which format you’re talking about. Depending on which side of the dateline your timezone is on you could wind up with different dates.

      Does your janky string format of “18-03-2024” suddenly has to become aware of the timezone if I tack on a “0:00” at the end of it? Or maybe you always will have timezone issues no matter what the precision of the time you want to store.

      I think you got it in your mind that you can’t do anything other than Timestamp=getdate() and if it’s a date only you have to use a string. That’s not the case. You can indeed translate a date into any number of formats, unix time is one of them. I assure you that 1710720000 will translate to the same janky “18-03-2024” format you’re using every single time unless you deliberately mess with timezones in code where you admit that you don’t want to deal with timezones. But your string jankiness break simply by someone parsing it with MM-dd-yyyy just as easily and this may not require someone to do something to deliberately break it. Depending on the library that’s being used and the localization settings of the OS, this can happen automatically. If your code will break because someone has different OS settings than yours, you are writing bad code.

      If the goal is to save space then your format uses 10 bytes, while the timestamp uses 4 (with Y2K38 problems) or 8 with 64 bit Epoch time. If you’re not too worried about saving space (you really shouldn’t be these days) then use the appropriate structs defined by the language you’re using and the DB you’re using.

      Even this would be better than a string:

      struct { int year byte month byte day }

      Six bytes as opposed to 10 and there would be no issues with confusion with the dd and MM parts of the string. It’s still shit (use existing date libraries instead) but still won’t have as many problems than what you’re doing. Seriously anything is better than just dumping a date into a string. And as I say, using the dd-MM-yyyy format is bad for multiple reasons.

      Though congratulations, you’ve convinced me that Y2K might’ve been a bigger problem than I thought given how adamant you are about repeating similar mistakes that caused those issues. I guess even when there’s very obvious problems with how someone’s doing things they will insist on doing things that way even when it’s pointed out all the problems with it. I can imagine someone in the 80s and 90s pointing out the Y2K problem to someone writing the code and getting some arrogant bullshit about how only mid-level programmers worry about that. “Experts put dates in strings LOL!”

      source

      • BorgDrone@lemmy.one ⁨9⁩ ⁨months⁩ ago

        Does your janky string format of “18-03-2024” suddenly has to become aware of the timezone

        No, there is no timezone, and that is the entire point. In the majority of cases you just want to store the local date. The point is that a local date or time is not necessarily a fixed point in time. If I have drinks at 18:00 every Friday, that doesn’t change when we switch to or from DST, it’s still 18:00 in local time. I don’t need a timezone, I know what timezone I live in.

        Now, in cases where timezones do matter, for example if you have a Zoom meeting with someone from another country, you can store as local time + timezone. But this is still very different from storing a Unix timestamp. This meeting will be at a specific time in a specific timezone, and the exact moment in time will adjust when changes are made to that timezone. Again, a Unix timestamp does not allow for this, as it’s always UTC.

        I assure you that 1710720000 will translate to the same janky “18-03-2024” format you’re using every single time unless you deliberately mess with timezones in code

        No, it doesn’t. You can’t convert it to any date unless you “mess with timezones”, because 1710720000 is a specific moment in time and you have to provide a timezone when converting it to a date. You are mistaking the fact that some systems implicitly use UTC when converting for some sort of of universal standard, because it’s not.

        Run the following Swift code:

        let d = Date(timeIntervalSince1970: 1710720000)
        print(d.formatted(date: .complete, time: .omitted))
        

        You’ll get a different date depending on your location.

        If your code will break because someone has different OS settings than yours, you are writing bad code.

        Yes, and your bad code will break simply because you are abusing a datatype for something beyond it’s intended use. If you want to store an absolute point in time, by all means use a Unix timestamp, but if you want to store a local time you should never use it because it’s not mean for that and it doesn’t encode the information needed to represent a local time.

        Even this would be better than a string:

        struct { int year byte month byte day }

        Yes that’s fine. I’m not arguing that you should store it as a string, I’m arguing that you should store it as individual components, in whatever format, instead of seconds since the epoch. As long as the format is well specced it doesn’t really matter. Strings are used all the time for representing dates by the way. For example, ASN.1, which is used everywhere, stores dates and time as strings and it’s perfectly fine as the format is specified unambigiously.

        Six bytes as opposed to 10

        In what archaic system are int’s still 4 bytes? Int is 64-bits, or 8 bytes, on any modern machine,

        source

        • -> View More Comments