GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Mx Amber Alex (she/it) (amberage@eldritch.cafe)'s status on Monday, 09-Dec-2024 00:18:20 JST Mx Amber Alex (she/it) Mx Amber Alex (she/it)

    Oh for fuck's sake…

    The timeline tool I wrote a while ago has some issue I can't track down. Dates, which should always end with T00:00:00.000Z, get seemingly random hours/minutes/seconds added to them, and sometimes, this causes them to get saved with a different date (i.e. 0100-09-01 gets saved as 0100-08-31T23:06:00.000Z).

    This has happened in a timeline I currently work with which takes place in very, very low years (as above, the year 100); I haven't been able to recreate this with current years (2023, 2024).

    Does anyone who knows JavaScript have any idea what's happening here?

    I use prompt() to ask for dates in YYYY-MM-DD format and then use new Date(...) to turn that into a date. Later, I use date.toLocaleString(...) to display that date again.

    I use JSON.stringify(...) to turn the object containing these dates into JSON, and later JSON.parse(...) to load them again.

    The entire source code is here.

    I could probably fix this dirty by just not using the JavaScript Date objects, but that would ruin localisation.

    I just want dates to be stored, without respect to time of day, only YYYY-MM-DD, and be displayed in an appropriate localisation (i.e. "Jun 10, 2024" for some and "10. Juni 2024" for others), without any timezone fuckery.

    #AskFedi #JavaScript

    In conversation about 6 months ago from eldritch.cafe permalink
    • Embed this notice
      Peter Krefting (nafmo@social.vivaldi.net)'s status on Monday, 09-Dec-2024 00:18:19 JST Peter Krefting Peter Krefting
      in reply to

      @amberage Are you using a location-based #timezone? The #tzdb tinezones revert back to solar time eventually, and those are at irregular seconds offsets.

      There are no meaningful clock times in our 24 hour clocks that far back, but the UTC scale is extended backwards without the offset changes.

      In conversation about 6 months ago permalink
    • Embed this notice
      Peter Krefting (nafmo@social.vivaldi.net)'s status on Monday, 09-Dec-2024 03:06:05 JST Peter Krefting Peter Krefting
      in reply to

      @amberage I am not a JavaScript expert, but try to specify the timezone as UTC and see if it works better.

      In conversation about 6 months ago permalink
    • Embed this notice
      Mx Amber Alex (she/it) (amberage@eldritch.cafe)'s status on Monday, 09-Dec-2024 03:06:07 JST Mx Amber Alex (she/it) Mx Amber Alex (she/it)
      in reply to
      • Peter Krefting

      @nafmo I have no idea, I just do new Date("0100-12-08").

      Another post could reproduce the issue with JSON.stringify(), so it seems the conversion to ISO strings within that method has issues with extremely ancient dates.

      In conversation about 6 months ago permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.