Skip to content

An existing DateTime attribute cannot be switched to localized by create or modify entity or alter entity #1521

Open

Description

@MendixMau

Summary

An existing DateTime attribute cannot be switched to localized by create or modify entity or alter entity. Related: #1297 and #1251 are about view entities only (closed).

Repro (generic)

create module Tmp;
create persistent entity Tmp.Item (Due: DateTime not localized);
create or modify persistent entity Tmp.Item (Due: DateTime);       -- stays not localized
alter entity Tmp.Item modify attribute Due: DateTime;              -- stays not localized
create or modify persistent entity Tmp.Item (Due: DateTime localized);  -- the only form that flips it

Expected

The statement decides localization (the Studio Pro default is localized), or modify preserves the flag under a documented rule.

Actual

Silent keep. Impact: a client compared the UTC wall clock to local now, so overdue chips were wrong.

Tested with: Mendix 11.15, mxcli v0.26.0, field run. Not retested on v0.27.0 (reading the flag back needs a project and describe).

Activity

  1. github-actions commented on Oct 16, 2026

    @github-actions

    Issue Triage

    Summary
    The user reports that create or modify entity and alter entity cannot change an existing DateTime attribute to localized; only redefining the attribute with the localized keyword works.

    Checklist of required bug‑report information

    Required info Present? Details
    mxcli version ✅ mxcli v0.26.0
    Mendix version ✅ Mendix 11.15
    Scenario (what was tried) ✅ MDL script showing the three statements
    Expected output ✅ Statement should decide localization (or preserve flag per a documented rule)
    Experienced output ✅ Attribute stays “not localized” (silent keep)
    AI bug report (mxcli diag --bundle or session log) ❌ Not provided

    Missing information
    Could you please attach the output of mxcli diag --bundle (or at least the relevant session log) so we can see the internal state and any warnings/errors? This will help us reproduce and fix the issue.

    Thank you for reporting the problem!


    Automated triage via OpenRouter — workflow source

  2. added a commit that references this issue on Oct 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions