# Date using TZ on Windows / MobaXterm-Cygwin

**URL:** <https://community.unix.com/t/date-using-tz-on-windows-mobaxterm-cygwin/397067>\
**Category:** UNIX for Advanced & Expert Users\
**Created:** [June 17, 2025, 11:18am UTC](https://community.unix.com/t/date-using-tz-on-windows-mobaxterm-cygwin/397067 "2025-06-17T11:18:40Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![newbie\_01](https://community.unix.com/letter_avatar/newbie_01/32/6_22734026db12803ebb3e059622ac3534.png) [@newbie\_01](https://community.unix.com/u/newbie_01)\
**Post date:** [June 17, 2025, 11:18am UTC](https://community.unix.com/t/date-using-tz-on-windows-mobaxterm-cygwin/397067/1 "2025-06-17T11:18:40Z")

</div>

Hi,

I believe this is behavior is because of MobaXterm-Cygwin but maybe there is a 'fix'/workaround for this?

```plaintext
MobaXterm-Cygwin uname -a gives below
CYGWIN_NT-10.0-WOW [hostname] 3.3.5(0.341/5/3) 2022-06-12 08:16 i686 GNU/Linux

```

On a real Linux Server, it gives this output which is what I am expecting

```plaintext
$ echo "$( date ) | $( TZ=Asia/Singapore date ) | $( date -u )"
Tue Jun 17 23:10:07 NZST 2025 | Tue Jun 17 19:10:07 +08 2025 | Tue Jun 17 11:10:07 UTC 2025

```

On a MobaXterm-Cygwin terminal, it gives below.

```plaintext
## Cygwin
echo "$( date ) | $( TZ=Asia/Singapore date ) | $( date -u )"
Tue Jun 17 23:11:11 NZST 2025 | Tue Jun 17 11:11:11 GMT 2025 | Tue Jun 17 11:11:11 UTC 2025

```

Is there a workaround so that the output from MobaXterm-Cygwin can give the same expected output as when I run the same command on a Linux server?

Has anyone not come up with a cool idea/function that display the current localtime and the UTC time and the time from several selected city/countries so I don't have to always check in the timeanddate website 🙂 Terrible headache having to work out the time differences so often ☹

---

<div class="post-metadata">

**Author:** ![vbe](https://community.unix.com/user_avatar/community.unix.com/vbe/32/266_2.png) [@vbe](https://community.unix.com/u/vbe)\
**Post date:** [June 21, 2025, 9:26am UTC](https://community.unix.com/t/date-using-tz-on-windows-mobaxterm-cygwin/397067/2 "2025-06-21T09:26:43Z")

</div>

Greetings

I would start by looking at what the TZ variable returns to try to understand how your system /why your system returns such a value

---

<div class="post-metadata">

**Author:** ![DrScriptt](https://community.unix.com/letter_avatar/drscriptt/32/6_22734026db12803ebb3e059622ac3534.png) [@DrScriptt](https://community.unix.com/u/DrScriptt)\
**Post date:** [June 28, 2025, 3:23pm UTC](https://community.unix.com/t/date-using-tz-on-windows-mobaxterm-cygwin/397067/3 "2025-06-28T15:23:46Z")

</div>

Make sure that your system has the correct time zone, date, and time. Date & time is usually easy to get correct enough. But if the time zone is wrong, you can still see correct date & time, but calculation to other time zones will be wrong.

Once you have good date & time, then you can put together a script that shows the dates in different cities relatively easily.

```plaintext
#!/usr/bin/env bash
TZ=American/NewYork date
TZ=America/Denver date

```

Type thing. -- You might want to play with the date command to generate fancier output that includes the city name; e.g.

```plaintext
TZ=America/NewYork date "+New York %Y-%m-%d %H:%M:%s"

```

N.B. It used to be common on PCs to set the system / BIOS clock to local time zone -or- UTC. Make sure you know what your system is set to and that the time zone configuration is set properly. Thankfully I think this is largely handled automatically now. But I've seen this problem as recent as five years ago.

P.S.A. All syntax from uncaffeinated memory, test & verify yourself.

---

<div class="post-metadata">

**Author:** ![system](https://community.unix.com/uploads/default/original/2X/c/c7e9e16a595259edafe88615719d5c5dcda035c2.png) [@system](https://community.unix.com/u/system)\
**Post date:** [August 27, 2025, 3:23pm UTC](https://community.unix.com/t/date-using-tz-on-windows-mobaxterm-cygwin/397067/4 "2025-08-27T15:23:57Z")

</div>

Closed on August 27, 2025, 3:23pm UTC

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.