starred/bambuddy-maziggy-1

Fork 0

mirror of https://github.com/maziggy/bambuddy.git synced 2026-05-09 08:25:54 +02:00

[GH-ISSUE #233] [Bug]: Setting a queued print from archive uses default date format #149

New issue

Closed

opened 2026-05-07 00:06:49 +02:00 by BreizhHardware · 6 comments

BreizhHardware commented

2026-05-07 00:06:49 +02:00

Owner

Originally created by @MemorianX on GitHub (Feb 2, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/233

Originally assigned to: @maziggy on GitHub.

Bug Description

I have my date set to dd/mm/yyyy and time to 24H, if I queue a print from the archive it ask me to select dates using mm/dd/yyyy and 12H

Expected Behavior

To select time using the format set in settings

Steps to Reproduce

queue a print from archive

Printer Model

Bambuddy Version

v0.1.6.2

Printer Firmware Version

01.07.02.00

Installation Method

Docker

Operating System

Linux (Ubuntu/Debian)

Relevant Logs / Support Package

Screenshots

No response

Additional Context

No response

Checklist

I have searched existing issues to ensure this bug hasn't already been reported
I am using the latest version of Bambuddy
My printer is set to LAN Only mode

Originally created by @MemorianX on GitHub (Feb 2, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/233 Originally assigned to: @maziggy on GitHub. ### Bug Description I have my date set to dd/mm/yyyy and time to 24H, if I queue a print from the archive it ask me to select dates using mm/dd/yyyy and 12H ### Expected Behavior To select time using the format set in settings ### Steps to Reproduce queue a print from archive ### Printer Model A1 ### Bambuddy Version v0.1.6.2 ### Printer Firmware Version 01.07.02.00 ### Installation Method Docker ### Operating System Linux (Ubuntu/Debian) ### Relevant Logs / Support Package ```shell ``` ### Screenshots _No response_ ### Additional Context _No response_ ### Checklist - [x] I have searched existing issues to ensure this bug hasn't already been reported - [x] I am using the latest version of Bambuddy - [x] My printer is set to LAN Only mode

BreizhHardware

2026-05-07 00:06:49 +02:00

closed this issue
added the
bug
label

BreizhHardware commented

2026-05-07 00:06:50 +02:00

Author

Owner

@maziggy commented on GitHub (Feb 3, 2026):

Fixed in branch 0.1.7b. Please let me know if it works for you.

@maziggy commented on GitHub (Feb 3, 2026): Fixed in branch 0.1.7b. Please let me know if it works for you.

BreizhHardware commented

2026-05-07 00:06:50 +02:00

Author

Owner

@leoschwarz commented on GitHub (Feb 3, 2026):

Hi @maziggy , first of all thank you for making this cool project which is something I personally had on my todo list for a while now too.

I experience the same issue with bambuddy v0.1.7 and a German locale & timezone.

When I try to save this queue entry:

This is what happens after I save, it swaps month & day, and converts the datetime to UTC (assuming the date is indeed April 2, it would be a 2 hour difference).

I normally work around this type of issue by storing the datetime in UTC always and then having the client convert it to the correct time zone or back to UTC when calling the sever, but it seems like here something is going wrong.

@leoschwarz commented on GitHub (Feb 3, 2026): Hi @maziggy , first of all thank you for making this cool project which is something I personally had on my todo list for a while now too. I experience the same issue with bambuddy v0.1.7 and a German locale & timezone. When I try to save this queue entry: <img width="505" height="328" alt="Image" src="https://github.com/user-attachments/assets/85b10635-9a3d-4b0d-9e19-06840bfdb029" /> This is what happens after I save, it swaps month & day, and converts the datetime to UTC (assuming the date is indeed April 2, it would be a 2 hour difference). <img width="505" height="328" alt="Image" src="https://github.com/user-attachments/assets/4d4ada69-d79c-4c3e-8f3a-eab455b27a7b" /> I normally work around this type of issue by storing the datetime in UTC always and then having the client convert it to the correct time zone or back to UTC when calling the sever, but it seems like here something is going wrong.

BreizhHardware commented

2026-05-07 00:06:50 +02:00

Author

Owner

@maziggy commented on GitHub (Feb 4, 2026):

Please use branch 0.1.8b and let me know if it works now.

@maziggy commented on GitHub (Feb 4, 2026): Please use branch 0.1.8b and let me know if it works now.

BreizhHardware commented

2026-05-07 00:06:50 +02:00

Author

Owner

@leoschwarz commented on GitHub (Feb 4, 2026):

@maziggy With 0.1.8b the time is correct but the date still does swap month and day.

In the editor, I put 5.2.2026 16:45 (5th February 2026) and this is what I am ending up:

If I can help create a proper test case for this I can look into it on the weekend.

@leoschwarz commented on GitHub (Feb 4, 2026): @maziggy With 0.1.8b the time is correct but the date still does swap month and day. In the editor, I put 5.2.2026 16:45 (5th February 2026) and this is what I am ending up: <img width="463" height="89" alt="Image" src="https://github.com/user-attachments/assets/317e3148-e918-4296-a8d3-c81a3bffdd19" /> <img width="166" height="32" alt="Image" src="https://github.com/user-attachments/assets/8702f5f1-24b3-460a-9c1b-654bb700ddb9" /> If I can help create a proper test case for this I can look into it on the weekend.

BreizhHardware commented

2026-05-07 00:06:50 +02:00

Author

Owner

@leoschwarz commented on GitHub (Feb 4, 2026):

I'm not sure if this was different in 0.1.7, but now I can correct the date in the picker after saving for the first time. It only seems to be a problem when creating the queue item initially.

@leoschwarz commented on GitHub (Feb 4, 2026): I'm not sure if this was different in 0.1.7, but now I can correct the date in the picker after saving for the first time. It only seems to be a problem when creating the queue item initially.

BreizhHardware commented

2026-05-07 00:06:50 +02:00

Author

Owner

@maziggy commented on GitHub (Feb 5, 2026):

Should be fixed in branch 0.1.8b. Please let me know if it works now.

@maziggy commented on GitHub (Feb 5, 2026): Should be fixed in branch 0.1.8b. Please let me know if it works now.